From nobody Mon Jan 2 22:19: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 947B0129508 for ; Mon, 2 Jan 2017 22:19: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pezXrXSWJIwc for ; Mon, 2 Jan 2017 22:18:58 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 2565E129434 for ; Mon, 2 Jan 2017 22:18:58 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id c47so455265202qtc.2 for ; Mon, 02 Jan 2017 22:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0qOMhexhsaSlv8dlnaHkuVW5Pkqcv1NYbFdg6mTnSsM=; b=nRvxsrKR5Eh9QE/Sn60/vZkw9Yd5kQrBpocD2mYpYNHJ3DMH+mpQcTPlhpoc6/JABj Ga2YfLbJwZwdVcU0Y53iLpH2qYf4Y6Wj0T53mIwHMdJrQQjMUcTZzr5vsZVfPSwm0AQA 6t9/V+xQSQNidcaactX+mptF8e8eWc6IeZRHwv426poaN/gKWh6rQE1B3pc3BVhbEbno yNyRAHoPcM5AFtYtBjo6a+NRxf5BIcMlorjeXxhIJyPj0ml3NKWhYivF8nGZ2b5AUbES g1jytz+OmGQdj/xxACZzYtPBQmVh2wCidr127WDDArTAK/PrOPsIdJ240Vrc/sEJWfbA k/KQ== 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=0qOMhexhsaSlv8dlnaHkuVW5Pkqcv1NYbFdg6mTnSsM=; b=oOW5AWNL5wFZojje6t2s0KpEleCkq0abQkHH8j0HemVgmRowCWhTgpGXxDQpyr2LFl HcQdtkwVRSjAqYsYERTl5G6FifeemONkI6eLnk1cjUIb/w9PsmYMXtJeKC2HxlYOquE1 a9n3LQiBwXLdGXv7Hq4wgdRIga37Ks52LRoyzZsGAoB7xQBHN9bmO697m0Z+LhZ5NaHM 7cTyCTp8o3fY23Ae8l8XtQRb0aTT9Oc68MvQFW4NxtaHg9CAJfN8ZmrdFZOtSH3yLENs WPi1Yyj1IxNYsN34iyePFJvi2Pv3bl9mZzxFIl0RTathhuwHfJgOEKhVLa7iOnc4Vo3x 8Hhg== X-Gm-Message-State: AIkVDXIJ0sNTPkaqldd9vmBOGhGC3jIEQ9Py2OjjGCA5W70yN+mNZaHq1NQWID2zjjK6HYx0Uw/COkZfrbpeOA== X-Received: by 10.200.48.28 with SMTP id f28mr62983878qte.247.1483424337206; Mon, 02 Jan 2017 22:18:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Mon, 2 Jan 2017 22:18:56 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 3 Jan 2017 17:18:56 +1100 Message-ID: Subject: Re: Stream vs. connection To: Jim Roskind Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , Ian Swett , "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 06:19:00 -0000 Performing thread-necromancy... On 11 December 2016 at 09:31, Jim Roskind wrote: > PADDING frames serve different functions, and should not interact with > limitations/meanings on PING frames. Is the implication that a PING frame has to be immediately acknowledged, whereas other frame types can be acknowledged as needed? PING has two purposes in HTTP/2: - check that the link is still usable (it's cheaper than a full handshake) - measure end-to-end latency My understanding was that the use of explicit timestamps in acknowledgments would have obviated any need to respond aggressively to pings as far as timing goes. That only leaves the former use, and isn't that addressed by PADDING as well? PING (and PADDING) are one of the ways that implementations can be abused, so we need to be very crisp about motivating their existence. PADDING has a fairly simple and elegant design - read zero, ignore the remainder of the packet after maybe checking it - and a direct security benefit in terms of traffic analysis resistance. PING seems less well motivated given that it could be reliably replicated by a packet containing all zeros (i.e., PADDING). From nobody Tue Jan 3 08:32: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 A864A12968F for ; Tue, 3 Jan 2017 08:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dww9agHh1NOJ for ; Tue, 3 Jan 2017 08:32:48 -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 2F46F129669 for ; Tue, 3 Jan 2017 08:32:48 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cOS0z-0003ML-Px for quic@ietf.org; Tue, 03 Jan 2017 17:32:46 +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 1cOS0t-0000d8-Ql for quic@ietf.org; Tue, 03 Jan 2017 11:32:43 -0500 Received: (qmail 20678 invoked from network); 3 Jan 2017 16:32:39 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.5.168]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Jan 2017 16:32:38 -0000 From: "Christian Huitema" To: "'Martin Thomson'" , "'Jim Roskind'" References: In-Reply-To: Date: Tue, 3 Jan 2017 08:32:34 -0800 Message-ID: <084d01d265de$fe1352b0$fa39f810$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHsl9c0ojBcnjkBCGV2pJTNH51tdAKmZkA5A2UKr10CBu+xlwMRH3K7oJlvsZA= Content-Language: en-us Subject: RE: Stream vs. connection X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.20) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrqQDSj8EAHHIi8tJqmVa0PRcOb18WfxGyg6Om6u4YYm/kaHCm2ZAGR0mKg Z/+aZvA5hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aIhQRCdMNhge1Unb77YyuZq7hPfc1PRs0uplqZ3D/mkTrRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f3u07h1Ar0asfEVCjJZw/E01 aDvSI66S1J0VQ44N+76Fg3Z2rsg2JqCsXQM/UhHNbqmxVEE6gtF+B/lEIPzms74rHdmmurdkSlp8 bL7MuNSeJ6fVbIdD0RyyBL+RsQXLIsIclqURQOfTUwDe+Ri01fK//LgD8r/EmKnkLuRbKmSGxlp0 rzUdrgqjB31bCd9Lg/Y4ocfmWv3Fe9Iziczdq+A= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'Mike Bishop' , 'Ian Swett' , quic@ietf.org, =?utf-8?Q?'Mirja_K=C3=BChlewind'?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:32:50 -0000 On Monday, January 2, 2017 10:19 PM, Martin Thomson wrote: > ... > PING has two purposes in HTTP/2: > - check that the link is still usable (it's cheaper than a full = handshake) > - measure end-to-end latency It is also a very simple way to implement Tail Loss Probe. > ...=20 > PING seems less well motivated given that it could be reliably > replicated by a packet containing all zeros (i.e., PADDING). But then there is the "ACK of ACK" problem. Each of these empty packets = consumes a sequence number. The ACK of the empty packet also consumes a = sequence number. If the policy is to ACK all pending packets, then QUIC = generates an unending ACK ping pong. To stop the ping pong the = implementation needs to distinguish between packets that need an ACK, = and packets for which the ACK can wait. In the absence of data, PING is = an easy way to do that. -- Christian Huitema From nobody Tue Jan 3 14:05:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCCB1297B8 for ; Tue, 3 Jan 2017 14:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mMQJ1omem6v for ; Tue, 3 Jan 2017 14:05:05 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E78D129AA6 for ; Tue, 3 Jan 2017 14:04:57 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id u25so378620597qki.2 for ; Tue, 03 Jan 2017 14:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JK/l0EDPpaczegTg5bENz+pVDrstMgKWrksndgAHWW0=; b=q/ZFEirjxyKluzfuvXztgmFPdRbuwCUeCVd6Y+krP1kS4hyKdrKbnliLcvLLPeuRUR nUGKi2L/sNf30b8z67RENRm3PlchllHN1FHgtNvbWefpzW3DGfdR7GqOESaseQSR/Pal pXeS4ALLNRqKh+uaKooLTBuWZQQnlhf6E+mjuBpfEMe8LfWxjZlQJvfbj/usG+AfSIuy UnhEiMbai3eUHaOCEA9lcOY2W1kFsDclkL4o6cCYjik15LPGZWKEvGNAw3XzvcAsseP/ SimMeQf1F7O/V8cySy2902/Jz1AFr48sRI/+jIH7n8CXYCqRBaEfiCT1iJkP5K43cl/9 +DOQ== 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=JK/l0EDPpaczegTg5bENz+pVDrstMgKWrksndgAHWW0=; b=ZANyq6+x3A9m9VyqPwRqKAxrKzM5Kzc8oLrDJQLeQCGKCZ4jPyGxV4nSNPFgeDjtzo PAhfGD0byf/Z3y313JGeQfbq7h47VIZL2fZaXa8/mJogahraz3BfI9ePUeOGtZXLmrUA SYtBVAW7pgJsts6XoiKkDDiGcoKNKDSugs/Txqwt11py0dnI2PryJ7LcBNLFhLAymlbj MGQHZh08VmuEhEbu29uLaWuqviB9vk1PIBK4SFAyuhBSORt7X5guRXVujWonGkVg0tws RNUNAGqivQn1V1NvRCuZwrxPZ9qJP3RSc2nP4tqw6cZFOgyPGGS/gs4qzto46djPCHx1 Lwhw== X-Gm-Message-State: AIkVDXJ1T/JSkdhmiDaihorPskqpqTbjYmh3lI2b1OyGvCHqQVLXSyVl4yp1fXIShxzPHp78zwE/gn2ajA1oOQ== X-Received: by 10.55.138.2 with SMTP id m2mr38488444qkd.115.1483481096434; Tue, 03 Jan 2017 14:04:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 3 Jan 2017 14:04:55 -0800 (PST) In-Reply-To: <084d01d265de$fe1352b0$fa39f810$@huitema.net> References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> From: Martin Thomson Date: Wed, 4 Jan 2017 09:04:55 +1100 Message-ID: Subject: Re: Stream vs. connection To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jim Roskind , Ian Swett , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Mike Bishop X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Jan 2017 22:05:07 -0000 On 4 January 2017 at 03:32, Christian Huitema wrote: > But then there is the "ACK of ACK" problem. Each of these empty packets c= onsumes a sequence number. The ACK of the empty packet also consumes a sequ= ence number. If the policy is to ACK all pending packets, then QUIC generat= es an unending ACK ping pong. To stop the ping pong the implementation need= s to distinguish between packets that need an ACK, and packets for which th= e ACK can wait. In the absence of data, PING is an easy way to do that. That's a good reason. So which of the frame types demand acknowledgment? clearly not ACK... STREAM - yes ACK - no STOP_WAITING - ? WINDOW_UPDATE - ? BLOCKED - ? RST_STREAM - ? PADDING - no PING - always CONNECTION_CLOSE - ? GOAWAY - ? From nobody Tue Jan 3 14:39: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 CDBEC129861 for ; Tue, 3 Jan 2017 14:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnIPwnwBdca2 for ; Tue, 3 Jan 2017 14:39:31 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67A7129860 for ; Tue, 3 Jan 2017 14:39:31 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cOXju-0008Ee-2C for quic@ietf.org; Tue, 03 Jan 2017 23:39:31 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cOXjp-000604-Ps for quic@ietf.org; Tue, 03 Jan 2017 17:39:29 -0500 Received: (qmail 26348 invoked from network); 3 Jan 2017 22:39:24 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.5.168]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Jan 2017 22:39:24 -0000 From: "Christian Huitema" To: "'Martin Thomson'" References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> In-Reply-To: Date: Tue, 3 Jan 2017 14:39:20 -0800 Message-ID: <09e601d26612$3a982660$afc87320$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHsl9c0ojBcnjkBCGV2pJTNH51tdAKmZkA5A2UKr10CBu+xlwMRH3K7AXOegJQA7oDYZKCGw39A Content-Language: en-us Subject: RE: Stream vs. connection X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.24) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrI6wngmA6N5cOsKtZ7q4shRcOb18WfxGyg6Om6u4YYm6Wsw2kakWcadtpy RGiw72s5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+gxQRCdMNhge1Unb77YyuZq5uIO3Frtq7FEWibdhbQZcdRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYabuun6ZKppsJR0NnKfJ6WAeYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8tEzDd JFEeZx0L8qYzBLK5yNBqLkXGaznuCfaQ1w/JpOE= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'Jim Roskind' , 'Ian Swett' , 'IETF QUIC WG' , =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , 'Mike Bishop' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Jan 2017 22:39:34 -0000 On Tuesday, January 3, 2017 2:05 PM, Martin Thomson wrote: > On 4 January 2017 at 03:32, Christian Huitema = wrote: >> But then there is the "ACK of ACK" problem. Each of these empty = packets consumes a sequence >> number. The ACK of the empty packet also consumes a sequence number.=20 >> If the policy is to ACK all pending packets, then QUIC generates an = unending ACK ping pong.=20 >> To stop the ping pong the implementation needs to distinguish between = packets that need=20 >> an ACK, and packets for which the ACK can wait. In the absence of = data, PING is an easy=20 >> way to do that. > > That's a good reason. So which of the frame types demand > acknowledgment? clearly not ACK... Hum. Before answering the question, let's note that it would be nice if = this was somehow discussed in a revision of draft-ietf-quic-transport. Now, my personal answer to the question would be, "if a packet contains = stream specific frames, it should be acknowledged at the first = opportunity." But that leaves issues like connection close or windows = update. The real test is, what would the sender do if the packet was = known lost? ACK and STOP WAITING don't need to be retransmitted, because = they are superseded by the next ACK or STOP WAITING frame. = CONNECTION_CLOSE would typically be retransmitted 2 or 3 times, because = it is kind of desirable to ensure that both ends have the same view of = the connection. Same for GO AWAY. BLOCKED is informational. So, my = version of your table would be: STREAM - yes ACK - no STOP_WAITING - no WINDOW_UPDATE - yes BLOCKED - no RST_STREAM - yes PADDING - no PING - always CONNECTION_CLOSE - yes GOAWAY - yes -- Christian Huitema From nobody Tue Jan 3 15:30: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 E86461294BB for ; Tue, 3 Jan 2017 15:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, 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 md_NpJXh5PVn for ; Tue, 3 Jan 2017 15:29:59 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4486C1294B3 for ; Tue, 3 Jan 2017 15:29:59 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id i68so232058386uad.0 for ; Tue, 03 Jan 2017 15:29: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=ZRhC5c2Y1TD+87McZB1opneRyXrVqS3XnjV39djWNHQ=; b=FdIbfA4Kze8EG8l0TDPU0/tHF+oFXoQV8VErAHXDCMNYXRuSaS8c0wt9dL04RQSZEu x5eBXvc0GAmX/fo0AzGp4Vcj6raVb2NtlrVGR4L9j0W3ZrtEHME7fsl0fGfHfrx596E9 kgx3h2wGx22xq3iQneNIzlAWRlJT6KVE0hmow57cln/kGG9m73fYZZnbaoG3lApGFeGc bKxV/MyhuFij336iEDwLL9mtB4UCrBav+t2CMjHtu1l+A3nul9+cebR7ORt9T8QNrEDf aM4r0NqQu0Ha5AaZ2EWTZOFZTS3dCqvVPeAwYOsBy5UwZPH1qBgEAdq0RTawQ/AyvwQO yCwQ== 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=ZRhC5c2Y1TD+87McZB1opneRyXrVqS3XnjV39djWNHQ=; b=nLrYDxy6/eG48U/tNdFRw0IJPxIw9CIe2XDIW7MLKLt58g5ZyFcRc7dAsjZ/OqR/b2 akuEIwVaQjY0ASU28WCX2pa6bYzezhnZRiTMCdNdsxmVvMSrUzKO9gRV//AewDO6wzUn 8jPPAuIaKNwaYt3KY+f67t0u1UQG3fJ2CzzjitQts7gVDiAmjcyLi6RhzcP7tD/XrVOf ounmAOor2WSp4+w3IkeiNrxaj2JNig8KdbuKYqtNK7HC70e1SQ18I77PflzMDdK+rilZ QrI7A0jj1kPKRC5yp2tlcOUgLfVC+NlBbJNaH2kOQOWUr165PSfndoGFJFU3ijUW3qOs U5Qw== X-Gm-Message-State: AIkVDXLW4hXBCGAtvgF1i+gN64t46bWW3H3yVTtGVaFc+YhOn5LnYBQVDYXcNopsZyEvrIOBFRuNPMYyHVhf8Eeg X-Received: by 10.159.48.222 with SMTP id k30mr49817148uab.2.1483486198228; Tue, 03 Jan 2017 15:29:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 3 Jan 2017 15:29:57 -0800 (PST) In-Reply-To: <084d01d265de$fe1352b0$fa39f810$@huitema.net> References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> From: Jana Iyengar Date: Tue, 3 Jan 2017 15:29:57 -0800 Message-ID: Subject: Re: Stream vs. connection To: Christian Huitema Content-Type: multipart/alternative; boundary=f403045dd8f0e02f1e0545390ba8 Archived-At: Cc: Mike Bishop , Ian Swett , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Jim Roskind , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:30:01 -0000 --f403045dd8f0e02f1e0545390ba8 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 3, 2017 at 8:32 AM, Christian Huitema wrote: > On Monday, January 2, 2017 10:19 PM, Martin Thomson wrote: > > ... > > PING has two purposes in HTTP/2: > > - check that the link is still usable (it's cheaper than a full > handshake) > > - measure end-to-end latency > > It is also a very simple way to implement Tail Loss Probe. > Additionally, in the current Google implementation, it's also used to measure reachability to the peer over a new network path. A PING frame is quite useful, and I'd argue against removing it. > ... > > PING seems less well motivated given that it could be reliably > > replicated by a packet containing all zeros (i.e., PADDING). > > But then there is the "ACK of ACK" problem. Each of these empty packets > consumes a sequence number. The ACK of the empty packet also consumes a > sequence number. If the policy is to ACK all pending packets, then QUIC > generates an unending ACK ping pong. To stop the ping pong the > implementation needs to distinguish between packets that need an ACK, and > packets for which the ACK can wait. In the absence of data, PING is an easy > way to do that. Padding is primarily used in the CHLO and SHLO packets, to pad the packets to a MaxPacketSize. QUIC currently relies on the use of PADDING to detect whether MaxPacketSize is usable for the rest of this connection... if the packet size is too large for the network to transmit, the handshake fails, and the connection does not proceed. An implementation could consider doing other PMTU size checks at this point, using PADDING to control packet size. I'd argue against combining them since the acking semantics are different. PADDING frames by themselves currently do not generate ACKs, while PINGs do. (This might be what Christian is saying.) > -- Christian Huitema > > > > > --f403045dd8f0e02f1e0545390ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 3, 2017 at 8:32 AM, Christian Huitema <huitema@huitema.net&g= t; wrote:
On Monday, January 2, 20= 17 10:19 PM, Martin Thomson wrote:
> ...
> PING has two purposes in HTTP/2:
> - check that the link is still usable (it's cheaper than a full ha= ndshake)
> - measure end-to-end latency

It is also a very simple way to implement Tail Loss Probe.

Additionally, in the current Google implementati= on, it's also used to measure reachability to the peer over a new netwo= rk path. A PING frame is quite useful, and I'd argue against removing i= t.

> ...
> PING seems less well motivated given that it could be= reliably
> replicated by a packet containing all zeros (i.e., PADDING).

But then there is the "ACK of ACK" problem. Each of these = empty packets consumes a sequence number. The ACK of the empty packet also = consumes a sequence number. If the policy is to ACK all pending packets, th= en QUIC generates an unending ACK ping pong. To stop the ping pong the impl= ementation needs to distinguish between packets that need an ACK, and packe= ts for which the ACK can wait. In the absence of data, PING is an easy way = to do that.

Padding is primarily used in th= e CHLO and SHLO packets, to pad the packets to a MaxPacketSize. QUIC curren= tly relies on the use of PADDING to detect whether MaxPacketSize is usable = for the rest of this connection... if the packet size is too large for the = network to transmit, the handshake fails, and the connection does not proce= ed. An implementation could consider doing other PMTU size checks at this p= oint, using PADDING to control packet size.

I'= d argue against combining them since the acking semantics are different. PA= DDING frames by themselves currently do not generate ACKs, while PINGs do.<= /div>
(This might be what Christian is saying.)

=
-- Christian Huitema





--f403045dd8f0e02f1e0545390ba8-- From nobody Tue Jan 3 15:41: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 4182D1294BA for ; Tue, 3 Jan 2017 15:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, 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 D20Aqu8NbDRr for ; Tue, 3 Jan 2017 15:41:30 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8B81294B4 for ; Tue, 3 Jan 2017 15:41:30 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id y197so132372229vky.2 for ; Tue, 03 Jan 2017 15:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uVmUFxc8dxkenxk9uy8xSnNsMv1o7oInzB7UyqUwo34=; b=LhWJUFSWjZ3gm3ME4PgUR67y7ZAQjEauTS4mL6Pt73gnoA3PfGP6QHBgLxBA77qOQi Jhjsi0rNbDkltYiMPZL8FTo5Tg1WJgz1a8c8TKRUcZvWRF5boS8HyOV72kqxhBqA1cs3 yJwpJ7ABNCrvrBqN9dCaBhU2g8Q1siDgn19ikwGy8eAsqvr9dCnp74s9Uow/wGlaOcdH z7jjti2BcPzX97pSU5kEDckjbv/T7VN8GydVx34CL6WjDBpUz+EAiWb5s48Tpf1oIS9S /DlCejl0VOl8UstiiRlWVS93AhI/nd8ml18Yv69Pr0g5X0LrgRAifMoQWPZwrVyoqOKt +R1Q== 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=uVmUFxc8dxkenxk9uy8xSnNsMv1o7oInzB7UyqUwo34=; b=VBjxRj84mn/GvlwgowV5tq8y6vpbrElH7L6dJAdHfFXjuAsFNv1rEnv9v1hzr23B87 F1pW8dqPwcwASe3ijT6NkoYS8dhEUT5tci9M2ZSE9ZNHs3Zacsmywzt81WwPLVGe7Ye2 xfNkiWGnO87hOn1T+skzzLBOe/Ux50HyoTMbvNwO5HU9gD983+UX6fX7vE30fhU2Wa4I 6tyJpDBGJjLDFPhOQIjwSm4FSoG0G60RlH6eh7P8/NA0TvG/BzuPhKRu+FLa4Okc1I2x cAwT81JXN7+pPsJg3N86GAbXT9d5YfQZYRIydO+3QKIw3jeTp8nwBA5zmCGRepZitIi4 T4eQ== X-Gm-Message-State: AIkVDXKnMs+PKV4ePMljnS9HBqHeVQPBlAAeAhv089ge1brwlYd2wL7KIqq1geGN68vRgaxgF8/wNFNOut/NBWe4 X-Received: by 10.31.164.204 with SMTP id n195mr17983608vke.58.1483486889014; Tue, 03 Jan 2017 15:41:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 3 Jan 2017 15:41:28 -0800 (PST) In-Reply-To: References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> From: Jana Iyengar Date: Tue, 3 Jan 2017 15:41:28 -0800 Message-ID: Subject: Re: Stream vs. connection To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1142e10a0cd69c05453935e4 Archived-At: Cc: Mike Bishop , Ian Swett , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , Jim Roskind , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:41:32 -0000 --001a1142e10a0cd69c05453935e4 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 3, 2017 at 2:04 PM, Martin Thomson wrote: > On 4 January 2017 at 03:32, Christian Huitema wrote: > > But then there is the "ACK of ACK" problem. Each of these empty packets > consumes a sequence number. The ACK of the empty packet also consumes a > sequence number. If the policy is to ACK all pending packets, then QUIC > generates an unending ACK ping pong. To stop the ping pong the > implementation needs to distinguish between packets that need an ACK, and > packets for which the ACK can wait. In the absence of data, PING is an easy > way to do that. > > > That's a good reason. So which of the frame types demand > acknowledgment? clearly not ACK... > > STREAM - yes > ACK - no > STOP_WAITING - ? > WINDOW_UPDATE - ? > BLOCKED - ? > RST_STREAM - ? > PADDING - no > PING - always > CONNECTION_CLOSE - ? > GOAWAY - ? > The current strategy is described in the draft, in Section 7 (Packetization and Reliability): A receiver acknowledges receipt of a received packet by sending one or more ACK frames containing the packet number of the received packet. To avoid perpetual acking between endpoints, a receiver MUST NOT generate an ack in response to every packet containing only ACK frames. However, since it is possible that an endpoint sends only packets containing ACK frame (or other non-retransmittable frames), the receiving peer MAY send an ACK frame after a reasonable number (currently 20) of such packets have been received. Section 7 lays out what frames MUST and MUST NOT be retransmitted, which defines which frames are retransmittable. PADDING frames are non-retransmittable (as explained earlier in Section 7), and therefore do not evoke a timely ack (since the receiver knows that the sender won't retrasmit this frame.) PING frames are considered retransmittable, and therefore evoke an ack, perhaps with a delayed ack timer. --001a1142e10a0cd69c05453935e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 3, 2017 at 2:04 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
On 4 January 2017 at 03:32, Christian Huitema <= huitema@huitema.net> wrote: > But then there is the "ACK of ACK" problem. Each of these em= pty packets consumes a sequence number. The ACK of the empty packet also co= nsumes a sequence number. If the policy is to ACK all pending packets, then= QUIC generates an unending ACK ping pong. To stop the ping pong the implem= entation needs to distinguish between packets that need an ACK, and packets= for which the ACK can wait. In the absence of data, PING is an easy way to= do that.


That's a good reason.=C2=A0 So which of the frame types demand acknowledgment?=C2=A0 clearly not ACK...

STREAM - yes
ACK - no
STOP_WAITING - ?
WINDOW_UPDATE - ?
BLOCKED - ?
RST_STREAM - ?
PADDING - no
PING - always
CONNECTION_CLOSE - ?
GOAWAY - ?

The current strategy is desc= ribed in the draft, in Section 7 (Packetization and Reliability):

   A receiver acknowledges rec=
eipt of a received packet by sending one
   or more ACK frames containing the packet number of the received
   packet.  To avoid perpetual acking between endpoints, a receiver MUST
   NOT generate an ack in response to every packet containing only ACK
   frames.  However, since it is possible that an endpoint sends only
   packets containing ACK frame (or other non-retransmittable frames),

   the receiving peer MAY send an A=
CK frame after a reasonable number
   (currently 20) of such packets have been received.

Section 7 lays out what frames MUST and MUS= T NOT be retransmitted, which defines which frames are retransmittable.=C2= =A0PADDING frames are non-retransmittable (as explained earlier in Section = 7), and therefore do not evoke a timely ack (since the receiver knows that = the sender won't retrasmit this frame.) PING frames are considered retr= ansmittable, and therefore evoke an ack, perhaps with a delayed ack timer.= =C2=A0

--001a1142e10a0cd69c05453935e4-- From nobody Tue Jan 3 16:07: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 AB5531294DD for ; Tue, 3 Jan 2017 16:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, 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 Y-BcPKqPikKp for ; Tue, 3 Jan 2017 16:07:19 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD391294DC for ; Tue, 3 Jan 2017 16:07:19 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id p9so280917715vkd.3 for ; Tue, 03 Jan 2017 16:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VtvJompQxDpWEXountslRqsuU/a36E55ea+XIy/FQb4=; b=vmdILx9QjcP1fGUSbAt/FuCg3Y6il13tW3BNO7rmo14KKiXMQ8z2Zw+8qVDfN4zUIG +4prZmNZixgO8jT5jzjuRHuOOTEEwWR9NzCrJEmLfog0R/KY+jGbLxRuQyS3xguh3Ys6 jan9MiBeJGcLDetFbJ8tDi4voLcg+3ZXrWW/rHfEI/ZQrgsHmDxN9O88CBOG+mbFQU74 vvN+N9A4u/mf6AM800eZ30IJpX+3FWKMGTKOAMok61ak4/5zkk40OUPueD/TXb+v8IMG PrB2MGNCCJlFywCgSJkLWdYRI8ITCbBTeH5ktRo+SAeOS4md9SD68XfBjmTCKDMmrhjh goXQ== 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=VtvJompQxDpWEXountslRqsuU/a36E55ea+XIy/FQb4=; b=Ix02nBDcYkXTg45K8Dq25EMy6SLaoLE8kn6a4O05f29nroyf4LiMcn5NMpyn4263EU 6U55zUaZ1XszOxj1HNBMAdg9Cy1K8J3wJSVtrfEEwaoAKH5uJ14VfMevBwVerbjVjspE MdEk/dz0Xx3sU+SHR0gSK1kPCMHZKqJR+kWP8ajH0pu5j/jDO4VzV9xLbqQxLUCNyrbm 8KcDvWIMupeSdr57FSH06wfs5XCqmyN5ZDv0x8xIKK5OOscJV0AmsS6ao4NgV20PKTgq /1cdJnzP9lAyANspwn8noNVl6elPqPlgrl1ZjEPmV4w5E+CDqQUn58fbSl3HJ/U6BRXf nq4Q== X-Gm-Message-State: AIkVDXKBG6c3FoYFnZbCJW2Tez0tSPn4j18j9LGJJouI8AqAZTFIlrnJp52/p9+cV5Il0WVM5epvPbFbCphd1tWm X-Received: by 10.31.87.6 with SMTP id l6mr18478217vkb.116.1483488438593; Tue, 03 Jan 2017 16:07:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 3 Jan 2017 16:07:17 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 3 Jan 2017 16:07:17 -0800 Message-ID: Subject: Re: Stream vs. connection To: Ian Swett Content-Type: multipart/alternative; boundary=001a114e5288695d0d0545399186 Archived-At: Cc: Mike Bishop , "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 00:07:21 -0000 --001a114e5288695d0d0545399186 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just adding a few thoughts while we're still speaking to dead threads (since I was on a blackout most of December): - ACK frame: Here the decision was made that data is ack=E2=80=99ed on a pe= r-packet >> basis (instead on per frame-basis). I believe this decision is fine (did= n=E2=80=99t >> actually further think about it so far). However, as these information a= re >> clearly aligned to packets, I think they should be part of the QUIC pack= et >> header. Here I assume that it does not make sense to send multiple ACK >> frames in one packet because they could always be combined to one (to sa= ve >> space). In this case it would be sufficient to have one flag in the gene= ral >> QUIC packet header that indicates if these information are present or no= t. >> > > As noted in the Issue Mike opened, there is currently no encrypted QUIC > packet header, but it could be added. > I'm not sure what the value of putting the ack in the packet header. Such a design would require consuming a flag bit, which would make it visible outside the encryption envelope that the packet contains an ack (this may not be important information, but it's certainly a difference from the current scheme.) Alternatively, you could have a "private flags" field inside the encrypted packet, but that splits the header into a publicly visible part and an encrypted part. This can be done (and it was the format with the QUIC packet header a while ago), but I'm not convinced that this complexity is warranted. SCTP has SACK frames, much like QUIC does, which makes it convenient to evolve this frame separately, independent of the packet format. (See propos= al for NR-SACKs which evolves SCTP's SACK frame.) - STOP_WAITING frame: At the first reading I didn=E2=80=99t really understa= nd what >> this is needed for because I didn=E2=80=99t fully internalize that packe= ts are not >> retransmitted (btw. that could be stated more clearly in the intro!). I >> understand that this is inevitable connection to how ack'ing is done and >> therefore I really don=E2=80=99t understand why this is a separate frame= at all. >> For me that could simply be one field in the ACK frame basically always >> indicating the last ACK information received. >> > > As noted in Issue #66(https://github.com/quicwg/base-drafts/issues/66), > it is not really necessary anymore. If not, merging into the ack frame a= s > you mentioned is a nice simplification, but I'd rather try removing it > first if possible. > I'll note in addition that STOP_WAITING used to be a part of the ACK frame in QUIC. Bear in mind that the information in ACK and STOP_WAITING are at different ends of the connection -- the sender of data sends STOP_WAITING, and the receiver of data sends ACKs. Combining them made our code more convoluted, since the treatment of the two pieces of information is basically done by completely different parts of the code: STOP_WAITING is for the part of the code that handles received packets, while the ACK information is for the part of the code that handles sent packets. None of this is to say that combining them is a bad idea; they're not related to each other in the packet, and it seemed reasonable to separate them out into separate frames. - jana One more general comment here: I=E2=80=99m also not convince that the ACK s= cheme >> chosen (and basically aligned to the TCP ACK scheme is the right choice >> here). Given that you don=E2=80=99t retransmit, wouldn't a NACK scheme m= ake more >> sense=E2=80=A6? Meaning that you indicate the highest (un-ordered) packe= t number >> seen as well as all packet numbers not seen since the packet number >> announced by the last STOP_WAITING value. Did you consider that previous= ly? >> > > QUIC@Google originally implemented that. In many ways they're mostly > equivalent, but it's critical to have the ack contain the smallest packet > being acked, otherwise the receiver can't unilaterally stop acking old > packets without receiving a stop waiting that raises the least unacked. > Once you have a largest acked and a set of nack ranges and a smallest > acked, you have something that looks more like ack ranges than nack range= s, > but one could word it as nack ranges. > > The new ack block approach is much simpler to implement, and removed quit= e > a few edge cases. I wrote a longer doc on why this change was made, but > I'm unable to find it at the moment. I'll try to find it as background > information. > > >> >> - PING frame: Having a whole frame for this really, really seems like >> overhead, while you only need on bit in the packet header and no >> frames/steam payload data are send at all=E2=80=A6 Btw. the reaction to = this signal >> is not specified: is the receiver supposed to send a ping back or a >> different packet or nothing at all? >> > > The overhead is pretty small, since it's just a byte. The reaction > specified in 6.8 is: "The receiver of a PING frame simply needs to ACK th= e > packet containing this frame." Would it be clearer as "only" instead > of simply? > > >> - CONNECTION_CLOSE and GO_AWAY: These two information bits are clearly >> per-connection. I also don=E2=80=99t really see a need for a CONNECTION_= CLOSE and a >> PUBLIC_RESET. I think there can be a way to combine these signals given = we >> have a mechanism for integrity checking. >> > > A connection close is encrypted and a public reset is not. If we have > non-spoofable public resets and we end up wanting to notify the path of t= he > close, I can imagine merging them into one packet, though I would want to > continue to encrypt connection close reason and details. In which case, > we'd still need both. > > Mirja >> >> >> > --001a114e5288695d0d0545399186 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just adding a few thoughts while we're still speaking = to dead threads (since I was on a blackout most of December):

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

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

I'm not sure what the value of putting the ack in the = packet header. Such a design would require consuming a flag bit, which woul= d make it visible outside the encryption envelope that the packet contains = an ack (this may not be important information, but it's certainly a dif= ference from the current scheme.) Alternatively, you could have a "pri= vate flags" field inside the encrypted packet, but that splits the hea= der into a publicly visible part and an encrypted part. This can be done (a= nd it was the format with the QUIC packet header a while ago), but I'm = not convinced that this complexity is warranted.

S= CTP has SACK frames, much like QUIC does, which makes it convenient to evol= ve this frame separately, independent of the packet format. (See proposal= for NR-SACKs which evolves SCTP's SACK frame.)

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

As noted in Issue #66(http= s://github.com/quicwg/base-drafts/issues/66), it is not really nec= essary anymore.=C2=A0 If not, merging into the ack frame as you mentioned i= s a nice simplification, but I'd rather try removing it first if possib= le.

I'll note i= n addition that STOP_WAITING used to be a part of the ACK frame in QUIC. Be= ar in mind that the information in ACK and STOP_WAITING are at different en= ds of the connection -- the sender of data sends STOP_WAITING, and the rece= iver of data sends ACKs.=C2=A0 Combining them made our code more convoluted= , since the treatment of the two pieces of information is basically done by= completely different parts of the code: STOP_WAITING is for the part of th= e code that handles received packets, while the ACK information is for the = part of the code that handles sent packets. None of this is to say that com= bining them is a bad idea; they're not related to each other in the pac= ket, and it seemed reasonable to separate them out into separate frames.

- jana

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

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

The new ack = block approach is much simpler to implement, and removed quite a few edge c= ases.=C2=A0 I wrote a longer doc on why this change was made, but I'm u= nable to find it at the moment.=C2=A0 I'll try to find it as background= information.
=C2=A0

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

The overhead is pretty small, since it's just a byte.=C2=A0 The reac= tion specified in 6.8 is: "The receiver of a PING frame simply needs t= o ACK the
=C2=A0 =C2=A0packet containing this frame." =C2=A0= Would it be clearer as "only" instead of simply?


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

Mirja




--001a114e5288695d0d0545399186-- From nobody Tue Jan 3 16:16: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 77FC11294F2 for ; Tue, 3 Jan 2017 16:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, 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 FWXWdVhuSdTA for ; Tue, 3 Jan 2017 16:15:56 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 B42B21270B4 for ; Tue, 3 Jan 2017 16:15:56 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id x186so281156738vkd.1 for ; Tue, 03 Jan 2017 16:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JZu0+nCxOqZKHHjt2KbQaksqFAJZIwDppNRKW8SZkCU=; b=Ty8zUclA7n2rrWGFdWmvtnGdP7RUXWflOEMaR9geKr2SGej5clLQmhqM8OKRn95Kqg thZgyLZxApkeHRWC4JnVr6dYTa8HN0yEePjRNbmEhZHHYzjtjQ9tyRoXIMFMYLhtcNkh CsN1wIr+T4wrqyYZPdrPa9Z9G/6OTtzKXMZdJhClH0HIJSaHkAxRh8c7qyzzGmAfzo4Y 9DOqsBxEHx0DBmTrSF6VQWyxMhsYclDWBn083vBy3E+vaoo1ZLtTZ1eWHWnzUdGbVOAh isdtw6DEbDSwPWfY15WtNPP9boQTxgEgpsRQVmeKNLwftYynzMvBzD+hlBlUsDGda3+H BV0g== 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=JZu0+nCxOqZKHHjt2KbQaksqFAJZIwDppNRKW8SZkCU=; b=NXMoSz/YUv/2wD6MibM4gS+V2au1CAqtn80f4EClVdCZMWh7zh9Ruc46rEtjmDwLtk xReTH/XyCnf36I9jp86XWD0tODTANjUwtTSOkSGQnBypEAgnrICK4OZ7mGOwykss0OLW qmhaDTIFuJjkSKdHhzFH6XLP7kCbrWNcdn31dHOm40c63jIErCH6vbMPF/UcgIfu2Dbb SJP489za13TDHHauHpAgXVNU4VteiCOsuaFn6PrwjUjR9/tOs+s+r7s27LcgmxW1gAfP kY6Gv7TqF7af1bYSJtghh2l3/f+nT6JVlm2DGFhbVB1eeSRyKAOdP/7ve8FLBahHOYpq KfEg== X-Gm-Message-State: AIkVDXLq4wqvfwfQmN2PM7ZlLQJrLoSJBQawUojhr7dnb8NX37mbENvtYwG93q/WaYkJ477PY55wppu+WvRVhJr1 X-Received: by 10.31.174.2 with SMTP id x2mr22596025vke.40.1483488955520; Tue, 03 Jan 2017 16:15:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 3 Jan 2017 16:15:54 -0800 (PST) In-Reply-To: <09e601d26612$3a982660$afc87320$@huitema.net> References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> <09e601d26612$3a982660$afc87320$@huitema.net> From: Jana Iyengar Date: Tue, 3 Jan 2017 16:15:54 -0800 Message-ID: Subject: Re: Stream vs. connection To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11438f5e39408f054539b0b8 Archived-At: Cc: Mike Bishop , Ian Swett , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Jim Roskind , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 00:16:00 -0000 --001a11438f5e39408f054539b0b8 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 3, 2017 at 2:39 PM, Christian Huitema wrote: > On Tuesday, January 3, 2017 2:05 PM, Martin Thomson wrote: > > > On 4 January 2017 at 03:32, Christian Huitema > wrote: > >> But then there is the "ACK of ACK" problem. Each of these empty packets > consumes a sequence > >> number. The ACK of the empty packet also consumes a sequence number. > >> If the policy is to ACK all pending packets, then QUIC generates an > unending ACK ping pong. > >> To stop the ping pong the implementation needs to distinguish between > packets that need > >> an ACK, and packets for which the ACK can wait. In the absence of data, > PING is an easy > >> way to do that. > > > > That's a good reason. So which of the frame types demand > > acknowledgment? clearly not ACK... > > Hum. Before answering the question, let's note that it would be nice if > this was somehow discussed in a revision of draft-ietf-quic-transport. > This is discussed in Section 7 on Packetization and Reliability. > Now, my personal answer to the question would be, "if a packet contains > stream specific frames, it should be acknowledged at the first > opportunity." But that leaves issues like connection close or windows > update. The real test is, what would the sender do if the packet was known > lost? ACK and STOP WAITING don't need to be retransmitted, because they are > superseded by the next ACK or STOP WAITING frame. CONNECTION_CLOSE would > typically be retransmitted 2 or 3 times, because it is kind of desirable to > ensure that both ends have the same view of the connection. Same for GO > AWAY. BLOCKED is informational. So, my version of your table would be: > > STREAM - yes > ACK - no > STOP_WAITING - no > WINDOW_UPDATE - yes > BLOCKED - no > RST_STREAM - yes > PADDING - no > PING - always > CONNECTION_CLOSE - yes > GOAWAY - yes > I missed BLOCKED in the list in Section 7 (I'll add it), but your inferences are spot on -- QUIC acks frames that are "retransmittable". In addition, there's a 20-packet count after which the receiver MAY send an ack frame to help the peer update RTT as well as clean out sent packet state (such as packet sent time). > > -- Christian Huitema > > > > > --001a11438f5e39408f054539b0b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 3, 2017 at 2:39 PM, Christian Huitema <= ;huitema@huitema.n= et> wrote:
On Tuesday, January 3, 2017 2:05 PM, Martin Thomson wrote:

> On 4 January 2017 at 03:32, Christian Huitema <huitema@huitema.net> wrote:
>> But then there is the "ACK of ACK" problem. Each of thes= e empty packets consumes a sequence
>> number. The ACK of the empty packet also consumes a sequence numbe= r.
>> If the policy is to ACK all pending packets, then QUIC generates a= n unending ACK ping pong.
>> To stop the ping pong the implementation needs to distinguish betw= een packets that need
>> an ACK, and packets for which the ACK can wait. In the absence of = data, PING is an easy
>> way to do that.
>
> That's a good reason.=C2=A0 So which of the frame types demand
> acknowledgment?=C2=A0 clearly not ACK...

Hum. Before answering the question, let's note that it would be = nice if this was somehow discussed in a revision of draft-ietf-quic-transpo= rt.

This is discussed in Section 7 on P= acketization and Reliability.
=C2=A0
Now, my personal answer to the question would be, "if a packet contain= s stream specific frames, it should be acknowledged at the first opportunit= y." But that leaves issues like connection close or windows update. Th= e real test is, what would the sender do if the packet was known lost? ACK = and STOP WAITING don't need to be retransmitted, because they are super= seded by the next ACK or STOP WAITING frame. CONNECTION_CLOSE would typical= ly be retransmitted 2 or 3 times, because it is kind of desirable to ensure= that both ends have the same view of the connection. Same for GO AWAY. BLO= CKED is informational. So, my version of your table would be:

STREAM - yes
ACK - no
STOP_WAITING - no
WINDOW_UPDATE - yes
BLOCKED - no
RST_STREAM - yes
PADDING - no
PING - always
CONNECTION_CLOSE - yes
GOAWAY - yes

I missed BLOCKED in the li= st in Section 7 (I'll add it), but your inferences are spot on -- QUIC = acks frames that are "retransmittable". In addition, there's = a 20-packet count after which the receiver MAY send an ack frame to help th= e peer update RTT as well as clean out sent packet state (such as packet se= nt time).
=C2=A0

-- Christian Huitema





--001a11438f5e39408f054539b0b8-- From nobody Tue Jan 3 16:21:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8370129408 for ; Tue, 3 Jan 2017 16:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4rFagd_aIUz for ; Tue, 3 Jan 2017 16:21:35 -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 57F3D1293F2 for ; Tue, 3 Jan 2017 16:21:35 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cOZKf-0003e2-AV for quic@ietf.org; Wed, 04 Jan 2017 01:21:33 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cOZKd-00009O-0S for quic@ietf.org; Tue, 03 Jan 2017 19:21:31 -0500 Received: (qmail 6532 invoked from network); 4 Jan 2017 00:21:30 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.5.168]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Jan 2017 00:21:29 -0000 From: "Christian Huitema" To: "'Jana Iyengar'" , "'Martin Thomson'" References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> In-Reply-To: Date: Tue, 3 Jan 2017 16:21:25 -0800 Message-ID: <0a4d01d26620$7d614900$7823db00$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHsl9c0ojBcnjkBCGV2pJTNH51tdAKmZkA5A2UKr10CBu+xlwMRH3K7AXOegJQA7oDYZAJLe+3PoHSHGuA= Content-Language: en-us Subject: RE: Stream vs. connection X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.17) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXp1dCJPpYKrPS+lrHBwpA+bRcOb18WfxGyg6Om6u4YYm2ReDx2Cg6ezRlrh h+1TF/s5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qhQRCdMNhge1Unb77YyuZq6UJ0/xPS+Y15rRlyzCsnb8RBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f3u07h1Ar0asfEVCjJZw/E01 aDvSI66S1J0VQ44N+76FDbVGhroT6ci0mTxrxNsIZ6mxVEE6gtF+B/lEIPzms74rHdmmurdkSlp8 bL7MuNSeJ6fVbIdD0RyyBL+RsQXLIsIclqURQOfTUwDe+Ri01fK//LgD8r/EmKnkLuRbKmSGxlp0 rzUdrgqjB31bCd9Lg/Y4ocfmWv3Fe9Iziczdq+A= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'Mike Bishop' , 'Ian Swett' , 'IETF QUIC WG' , =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , 'Jim Roskind' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Jan 2017 00:21:37 -0000 On Tuesday, January 3, 2017 3:41 PM, Jana Iyengar wrote: > The current strategy is described in the draft, in Section 7 = (Packetization and Reliability): > > A receiver acknowledges receipt of a received packet by sending one > or more ACK frames containing the packet number of the received > packet. To avoid perpetual acking between endpoints, a receiver = MUST > NOT generate an ack in response to every packet containing only ACK > frames. However, since it is possible that an endpoint sends only > packets containing ACK frame (or other non-retransmittable frames), > the receiving peer MAY send an ACK frame after a reasonable number > (currently 20) of such packets have been received. Maybe this should be updated to "... MUST NOT generate an ack in = response to every packet containing only ACK or STOP WAITING frames." It = is fairly natural for applications to generate ACK and STOP WAITING at = the same time, so you can easily build a perpetual acking scenario with = these two frame types.=20 -- Christian Huitema From nobody Tue Jan 3 16:35: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 D42B91294D8 for ; Tue, 3 Jan 2017 16:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, 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 A0DDTxitUKDH for ; Tue, 3 Jan 2017 16:35:26 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A851293DC for ; Tue, 3 Jan 2017 16:35:26 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id y9so6687947uae.2 for ; Tue, 03 Jan 2017 16:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0g0mxhPfnysLfLJm9TgG9cEbhGlkanf3zHSd5jmOLoY=; b=Zrj63sFKxYjsaUiBWX03GFiDMfL8MqlA84GHDrs+05R0shwnXHFU8bpeGZI1hLet/0 3KbKlxRT9YKZbpwLZ3dqT3rbbuRPhyCbbhd3c0w8hh7waP+i7hWt38DFxa0xrM8tHEwm beZLvIvrt+O0oomyfjmpP8gXyZsve2Ijb/NwRR5Ah42eNA5iQsZmae1mwUmMuVrr6BwM ojvhH0LEkpGVziT5degC/OVHHPyuz3nUzkkM6+KFYECwW/cRkGDTT5lOZER8vxM96zVV cK0wKqPWu9XvsDONN8yoN6DSV+WH7amSbDQvr5KePKHSHjO3zr6/RuQYC8FPlxuwzeq+ OlRQ== 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=0g0mxhPfnysLfLJm9TgG9cEbhGlkanf3zHSd5jmOLoY=; b=olsQj5lt/1Q0XnXWu6YPC8QstG3FF0rHKzwoyKVRD9tY95TZ3Fh3BNdE6dQsCkFXb8 gUzLDSGHOuKTtw9FV2z3pOJFy0PFNygvVlWjoWMl5Ih7PiVzN2EHBuPMLONHx/V6FFML mYYT/okB1qRLRORM9Uk+Q1vIrp6zLK+q33AbQIRkpkd7I6YhuVSbpm4zO5x7porqN4Eu kCp1pyMtEnWEBYn9W/jcIhglop/4P1yDwidPTxXPfQ9tD73qXfc1jN10cO6DVYLbNbNv /6oKM/B0Y5Jug8cdostZtyaVUOqorlVS5QEWGY3sp2fjAxKCw78MVRAkKXF2a7Yhs1XX u2Kw== X-Gm-Message-State: AIkVDXIBL1gUf0DLOB14DgTHX3+VHX6CnLn4volpXvMm7LoiY+SY4yE+oyKq8wj039EpjZUaBYeIQ2klJb+8ICef X-Received: by 10.176.16.30 with SMTP id f30mr48941688uab.58.1483490125337; Tue, 03 Jan 2017 16:35:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 3 Jan 2017 16:35:24 -0800 (PST) In-Reply-To: <0a4d01d26620$7d614900$7823db00$@huitema.net> References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> <0a4d01d26620$7d614900$7823db00$@huitema.net> From: Jana Iyengar Date: Tue, 3 Jan 2017 16:35:24 -0800 Message-ID: Subject: Re: Stream vs. connection To: Christian Huitema Content-Type: multipart/alternative; boundary=f403045e21e0f307ad054539f5e5 Archived-At: Cc: Mike Bishop , Ian Swett , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Jim Roskind , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 00:35:29 -0000 --f403045e21e0f307ad054539f5e5 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 3, 2017 at 4:21 PM, Christian Huitema wrote: > On Tuesday, January 3, 2017 3:41 PM, Jana Iyengar wrote: > > The current strategy is described in the draft, in Section 7 > (Packetization and Reliability): > > > > A receiver acknowledges receipt of a received packet by sending one > > or more ACK frames containing the packet number of the received > > packet. To avoid perpetual acking between endpoints, a receiver MUST > > NOT generate an ack in response to every packet containing only ACK > > frames. However, since it is possible that an endpoint sends only > > packets containing ACK frame (or other non-retransmittable frames), > > the receiving peer MAY send an ACK frame after a reasonable number > > (currently 20) of such packets have been received. > > Maybe this should be updated to "... MUST NOT generate an ack in response > to every packet containing only ACK or STOP WAITING frames." It is fairly > natural for applications to generate ACK and STOP WAITING at the same time, > so you can easily build a perpetual acking scenario with these two frame > types. I think we could state more broadly: "... MUST NOT generate an ack in response to every packet containing only non-retransmittable frames." What do you think? > > -- Christian Huitema > > > > --f403045e21e0f307ad054539f5e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 3, 2017 at 4:21 PM, Christian Huitema <= ;huitema@huitema.n= et> wrote:
On Tuesday, January 3, 2017 3:41 PM, Jana Iyengar= wrote:
> The current strategy is described in the draft, in Section 7 (Packetiz= ation and Reliability):
>
>=C2=A0 =C2=A0A receiver acknowledges receipt of a received packet by se= nding one
>=C2=A0 =C2=A0or more ACK frames containing the packet number of the rec= eived
>=C2=A0 =C2=A0packet.=C2=A0 To avoid perpetual acking between endpoints,= a receiver MUST
>=C2=A0 =C2=A0NOT generate an ack in response to every packet containing= only ACK
>=C2=A0 =C2=A0frames.=C2=A0 However, since it is possible that an endpoi= nt sends only
>=C2=A0 =C2=A0packets containing ACK frame (or other non-retransmittable= frames),
>=C2=A0 =C2=A0the receiving peer MAY send an ACK frame after a reasonabl= e number
>=C2=A0 =C2=A0(currently 20) of such packets have been received.

Maybe this should be updated to "... MUST NOT generate an ack i= n response to every packet containing only ACK or STOP WAITING frames."= ; It is fairly natural for applications to generate ACK and STOP WAITING at= the same time, so you can easily build a perpetual acking scenario with th= ese two frame types.

I think we could state= more broadly: "... MUST NOT generate an ack in response to every pack= et containing only non-retransmittable frames." What do you think?
=C2=A0

-- Christian Huitema




--f403045e21e0f307ad054539f5e5-- From nobody Tue Jan 3 16:36:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6781294DD for ; Tue, 3 Jan 2017 16:36: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 dC4snvgr6Jni for ; Tue, 3 Jan 2017 16:36:24 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 B2BE21293DC for ; Tue, 3 Jan 2017 16:36:24 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id d45so255931140qta.1 for ; Tue, 03 Jan 2017 16:36:24 -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=Cwbn4XdX8JcHQXuWb5vdk5c3Xyk9PBLNbWXxGN1KCHE=; b=m1hNyPnLH5pVDM9whYbPCb363GBeS4bbQunbDJeAUx2uqS1p3T+H01sQKRkNI3LZZx w+pHAvdvl3HFOdRYmmFzCO2SHrs6wG2txfQhmNvImaXSPjhtvMT3z36WJbohlx5L+crO b7Vi7qSeOBPkKkL+K0A5XoVekfJyByauPBzkwH8FaTTIdPaJBV2SGoF6PotbkQrGtPad djpO5iJLaUs2Smw0uLDoiswOHwecTGQPJWfsBx00q0KESXeuT3Soh1wAQNuh7eBKzi1e 8hY2Bgs7bSizZuqOYrmgqFfcQ0vIXGFcApjCarDUUrrnR35myWizhRIBMYIjyBN4dWRR PCSg== 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=Cwbn4XdX8JcHQXuWb5vdk5c3Xyk9PBLNbWXxGN1KCHE=; b=DQMCPLwja70HD088GKfWF6kYj74KaoKrHIWWmG11Swf8XDZuPWhNri+2tHMQkeCOh+ B4r2zUSyB9esxyRiL20xpbHLZ0yO0/Hljj35/g/xGxOcpqkwhhirc0Goq5YPsCnx+KqD F3CeyvMB3lfIynm6jZ7EqsGgCR8Jnv3k9PIRoFvitJJ3ByDEXznf3FI++npm4sEjRtmA /hKwqBZ3JswjQSuePibWoE0YQ5j6LFeHk8LqzK3bEz6u+n05BYXOeCTZ5jASU6qlwCsE DwJDX9q/gBdvHqg4OclyvrTH/xIUNgbFS+SamgmAwM7lzAoCqVhA9f87H5cK3Nv9v02h ZWzg== X-Gm-Message-State: AIkVDXLgn/dHiFFOHwQFBMkDYqSS/ZMCenEhBCB8Tl4DNvEb46CNdDdhCkoiVQx/luxkCzFCPwyPJZ1p/nR9aw== X-Received: by 10.200.46.249 with SMTP id i54mr59509771qta.13.1483490183859; Tue, 03 Jan 2017 16:36:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 3 Jan 2017 16:36:23 -0800 (PST) In-Reply-To: References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> <0a4d01d26620$7d614900$7823db00$@huitema.net> From: Martin Thomson Date: Wed, 4 Jan 2017 11:36:23 +1100 Message-ID: Subject: Re: Stream vs. connection To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , Ian Swett , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , Jim Roskind , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 00:36:26 -0000 On 4 January 2017 at 11:35, Jana Iyengar wrote: > I think we could state more broadly: "... MUST NOT generate an ack in > response to every packet containing only non-retransmittable frames." What > do you think? If we clearly designate frames as retransmittable or not, sure. From nobody Tue Jan 3 16:39: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 78E391294D8 for ; Tue, 3 Jan 2017 16:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, 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 PHhiULWotjve for ; Tue, 3 Jan 2017 16:39:20 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207071293DC for ; Tue, 3 Jan 2017 16:39:20 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 34so297778494uac.1 for ; Tue, 03 Jan 2017 16:39:20 -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=H4rzg86T6FUTjEnE8XrlXc5WT9vTYZ+NaE2bJtV0CG8=; b=uk/MqtdtJ+sbKp+DPBrSnBqHunIyo9eutBM9j0AgUBXH7H0Q8me0VKTu2CP/3O3s0e tAue8XI/h5sWhj6It/UNmKTIllPNB9uGMwi2Bo3Z2jk0ygTRCmJPqsEGyHN9Zb3SI2fC tfPL32WCrE1mzQG1Mv+TJly2eirdsKtBbCSoClH0HlqWb7Ac8Swc27EhDTM4Y+8JfMxA cznD1GJJkaZ6RRk36nAWBV2jgxnMC++q+iml6mz/q6RUuZmsu1KYgztar+tPxAlcGVM9 jnOnFgO5Y/4i6EH001SthzHCw2FrK8327WqbHjhWrXwgLtJvNG9NV2xb1AqiCViJtFsB Si1A== 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=H4rzg86T6FUTjEnE8XrlXc5WT9vTYZ+NaE2bJtV0CG8=; b=WW8p9KLADgPNeMjtZfAidjwo6vMuRfP4XVb+91OllVH4cMjIhEK3Hm6FpyExtJbI9u uAIZTFoa+lnZLeHo10+oZksm0tbujj5x3+8nmnmKzz19xcFyqKsQyBEVKVusHsE4v76h aLbIErpfcS881erP9RFDSX9GGtzhO50wWuAGWA/mMYxOB20hHZSdHnB5HUooql2MOH5c voa+Za91Y7FH/HKKnin/SFPW5kppyQI92GO9xaAd+4qeXT94LtYMgMQ6Vm+wPG2Cm5G8 jGtSz8tZ7qhUsibmg2JWBee+6bv6sw6mcGNnlpByJEAS4FDWvwq3J4vq+hYrL/GnnbSg WYKA== X-Gm-Message-State: AIkVDXLTnx31hH3Qu+D/orOD2rbzm/F2HD+/oqZYwfq7NB3MEt51tM4JnMS2BlZ7TIXaZbN/ZBiNy3IneKGPpD5D X-Received: by 10.176.80.187 with SMTP id c56mr48588682uaa.136.1483490359227; Tue, 03 Jan 2017 16:39:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 3 Jan 2017 16:39:18 -0800 (PST) In-Reply-To: References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> <0a4d01d26620$7d614900$7823db00$@huitema.net> From: Jana Iyengar Date: Tue, 3 Jan 2017 16:39:18 -0800 Message-ID: Subject: Re: Stream vs. connection To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c1917fae3e0c305453a0321 Archived-At: Cc: Mike Bishop , Ian Swett , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , Jim Roskind , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 00:39:21 -0000 --94eb2c1917fae3e0c305453a0321 Content-Type: text/plain; charset=UTF-8 > > If we clearly designate frames as retransmittable or not, sure. > We do in Section 7. --94eb2c1917fae3e0c305453a0321 Content-Type: text/html; charset=UTF-8
If we clearly designate frames as retransmittable or not, sure.

We do in Section 7.
--94eb2c1917fae3e0c305453a0321-- From nobody Tue Jan 3 16:45: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 D25981297A5 for ; Tue, 3 Jan 2017 16:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 csFPD7yOfRfD for ; Tue, 3 Jan 2017 16:44:58 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE991294D8 for ; Tue, 3 Jan 2017 16:44:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7C479D9309; Wed, 4 Jan 2017 01:44:56 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0jSk3vJoprnO; Wed, 4 Jan 2017 01:44:56 +0100 (MET) Received: from [192.168.178.33] (p5DEC2E6D.dip0.t-ipconnect.de [93.236.46.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2E8FFD9303; Wed, 4 Jan 2017 01:44:56 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Stream vs. connection From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 4 Jan 2017 01:44:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jana Iyengar X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Mike Bishop , Ian Swett , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 00:45:01 -0000 Hi Jana, thanks for the reply. Please see inline. > Am 04.01.2017 um 01:07 schrieb Jana Iyengar : >=20 > Just adding a few thoughts while we're still speaking to dead threads = (since I was on a blackout most of December): >=20 > - ACK frame: Here the decision was made that data is ack=E2=80=99ed on = a per-packet basis (instead on per frame-basis). I believe this decision = is fine (didn=E2=80=99t actually further think about it so far). = However, as these information are clearly aligned to packets, I think = they should be part of the QUIC packet header. Here I assume that it = does not make sense to send multiple ACK frames in one packet because = they could always be combined to one (to save space). In this case it = would be sufficient to have one flag in the general QUIC packet header = that indicates if these information are present or not. >=20 > As noted in the Issue Mike opened, there is currently no encrypted = QUIC packet header, but it could be added.=20 >=20 > I'm not sure what the value of putting the ack in the packet header. = Such a design would require consuming a flag bit, which would make it = visible outside the encryption envelope that the packet contains an ack = (this may not be important information, but it's certainly a difference = from the current scheme.) Alternatively, you could have a "private = flags" field inside the encrypted packet, but that splits the header = into a publicly visible part and an encrypted part. Yes, that was the assumption I=E2=80=99ve been taken. I was assuming = that there is an explicit encryption boundary rather than an implicit = one between packet and stream information. > This can be done (and it was the format with the QUIC packet header a = while ago), but I'm not convinced that this complexity is warranted. Can you further explain this complexity. Encrypting some header = information at the beginning of a packet shouldn=E2=80=99t be more = complicated that encrypting a frame, no? >=20 > SCTP has SACK frames, much like QUIC does, which makes it convenient = to evolve this frame separately, independent of the packet format. (See = proposal for NR-SACKs which evolves SCTP's SACK frame.) I don=E2=80=99t think this is comparable because SCTP acks chunks while = quic acks on a per packet basis; this it why it would be much more = natural for me to have these information on a per packet level. >=20 > - STOP_WAITING frame: At the first reading I didn=E2=80=99t really = understand what this is needed for because I didn=E2=80=99t fully = internalize that packets are not retransmitted (btw. that could be = stated more clearly in the intro!). I understand that this is inevitable = connection to how ack'ing is done and therefore I really don=E2=80=99t = understand why this is a separate frame at all. For me that could simply = be one field in the ACK frame basically always indicating the last ACK = information received. >=20 > As noted in Issue = #66(https://github.com/quicwg/base-drafts/issues/66), it is not really = necessary anymore. If not, merging into the ack frame as you mentioned = is a nice simplification, but I'd rather try removing it first if = possible. >=20 > I'll note in addition that STOP_WAITING used to be a part of the ACK = frame in QUIC. Bear in mind that the information in ACK and STOP_WAITING = are at different ends of the connection -- the sender of data sends = STOP_WAITING, and the receiver of data sends ACKs. Combining them made = our code more convoluted, since the treatment of the two pieces of = information is basically done by completely different parts of the code: = STOP_WAITING is for the part of the code that handles received packets, = while the ACK information is for the part of the code that handles sent = packets. None of this is to say that combining them is a bad idea; = they're not related to each other in the packet, and it seemed = reasonable to separate them out into separate frames. This implementation argument is also not really clear to me but I=E2=80=99= m assuming that this depends on other implementation choices you=E2=80=99v= e probably made. I guess there are multiple ways to implement this. My = understanding is that when you receive a packet you have to do certain = things: when you receive a packet with data frames, you may decide to = send an ack frame. When you receive an ACK frame you should probably = update the counter of the highest seen ACK and potentially decide to = generate an STOP_WAITING frame. However, the actual generation of these = frames can be done on the flight when you send out the packet; or you = just copy the latest ack counter in the encrypted part of the header of = the next packet you send out if ACK information and STOP_WAITING would = part of the packet header. =20 Mirja=20 >=20 > - jana >=20 > One more general comment here: I=E2=80=99m also not convince that the = ACK scheme chosen (and basically aligned to the TCP ACK scheme is the = right choice here). Given that you don=E2=80=99t retransmit, wouldn't a = NACK scheme make more sense=E2=80=A6? Meaning that you indicate the = highest (un-ordered) packet number seen as well as all packet numbers = not seen since the packet number announced by the last STOP_WAITING = value. Did you consider that previously? >=20 > QUIC@Google originally implemented that. In many ways they're mostly = equivalent, but it's critical to have the ack contain the smallest = packet being acked, otherwise the receiver can't unilaterally stop = acking old packets without receiving a stop waiting that raises the = least unacked. Once you have a largest acked and a set of nack ranges = and a smallest acked, you have something that looks more like ack ranges = than nack ranges, but one could word it as nack ranges. >=20 > The new ack block approach is much simpler to implement, and removed = quite a few edge cases. I wrote a longer doc on why this change was = made, but I'm unable to find it at the moment. I'll try to find it as = background information. > =20 >=20 > - PING frame: Having a whole frame for this really, really seems like = overhead, while you only need on bit in the packet header and no = frames/steam payload data are send at all=E2=80=A6 Btw. the reaction to = this signal is not specified: is the receiver supposed to send a ping = back or a different packet or nothing at all? >=20 > The overhead is pretty small, since it's just a byte. The reaction = specified in 6.8 is: "The receiver of a PING frame simply needs to ACK = the > packet containing this frame." Would it be clearer as "only" = instead of simply? >=20 >=20 > - CONNECTION_CLOSE and GO_AWAY: These two information bits are clearly = per-connection. I also don=E2=80=99t really see a need for a = CONNECTION_CLOSE and a PUBLIC_RESET. I think there can be a way to = combine these signals given we have a mechanism for integrity checking. >=20 > A connection close is encrypted and a public reset is not. If we have = non-spoofable public resets and we end up wanting to notify the path of = the close, I can imagine merging them into one packet, though I would = want to continue to encrypt connection close reason and details. In = which case, we'd still need both. >=20 > Mirja >=20 >=20 >=20 >=20 From nobody Tue Jan 3 17:39: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 3FB8512994F for ; Tue, 3 Jan 2017 17:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hawwaKQqPiLy for ; Tue, 3 Jan 2017 17:39:52 -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 BE4901298D3 for ; Tue, 3 Jan 2017 17:39:52 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cOaYQ-0001km-Mr for quic@ietf.org; Wed, 04 Jan 2017 02:39:51 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cOaYO-0003LO-Cq for quic@ietf.org; Tue, 03 Jan 2017 20:39:48 -0500 Received: (qmail 25318 invoked from network); 4 Jan 2017 01:39:46 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.5.168]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Jan 2017 01:39:46 -0000 From: "Christian Huitema" To: "'Jana Iyengar'" References: <084d01d265de$fe1352b0$fa39f810$@huitema.net> <0a4d01d26620$7d614900$7823db00$@huitema.net> In-Reply-To: Date: Tue, 3 Jan 2017 17:39:41 -0800 Message-ID: <0abc01d2662b$6cd040e0$4670c2a0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHsl9c0ojBcnjkBCGV2pJTNH51tdAKmZkA5A2UKr10CBu+xlwMRH3K7AXOegJQA7oDYZAJLe+3PARnmGAACx5aBsqBVkd8w Content-Language: en-us Subject: RE: Stream vs. connection X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.17) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrnQa8LbnSu+at6HvS+/BSIRcOb18WfxGyg6Om6u4YYm/AmIwlFYI+LrqWb uCxTDI05hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aIhQRCdMNhge1Unb77YyuZq7e5TcHeRxDJy1OhLf2uwNnRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f3u07h1Ar0asfEVCjJZw/E01 aDvSI66S1J0VQ44N+76FoQ5AQRaMdE14FPOYNhnbmqmxVEE6gtF+B/lEIPzms74rHdmmurdkSlp8 bL7MuNSeJ6fVbIdD0RyyBL+RsQXLIsIclqURQOfTUwDe+Ri01fK//LgD8r/EmKnkLuRbKmSGxlp0 rzUdrgqjB31bCd9Lg/Y4ocfmWv3Fe9Iziczdq+A= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'Mike Bishop' , 'Ian Swett' , =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , 'Jim Roskind' , 'IETF QUIC WG' , 'Martin Thomson' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 01:39:54 -0000 On Tuesday, January 3, 2017 4:35 PM, Jana Iyengar wrote: > On Tue, Jan 3, 2017 at 4:21 PM, Christian Huitema = wrote: > ... >> Maybe this should be updated to "... MUST NOT generate an ack in = response to=20 >> every packet containing only ACK or STOP WAITING frames." It is = fairly natural for=20 >> applications to generate ACK and STOP WAITING at the same time, so = you can easily=20 >> build a perpetual acking scenario with these two frame types. > > I think we could state more broadly: "... MUST NOT generate an ack in = response to every=20 > packet containing only non-retransmittable frames." What do you think? Works for me. -- Christian Huitema From nobody Thu Jan 5 07:34: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 A5C4512944C for ; Thu, 5 Jan 2017 07:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 8v7iczAU9GfP for ; Thu, 5 Jan 2017 07:34:46 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE52712995C for ; Thu, 5 Jan 2017 07:34:46 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s140so23318905qke.0 for ; Thu, 05 Jan 2017 07:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=Pe7UPPWi3fWc5p9PXNyVh3UbOcCqQUHgiqZUh4MSeBc=; b=Phw+lnO3up6Z854WVmmbVeZNyyJFqgGMq0PuedyjexDwGI57Oxgy9ncRR8GWnf+h+i M/IYIVVsRzqOLNkX2L2TM17jlZgImfTn4ycD5v22zGJ23hifUETRI6lQmzfejdwcrifZ K1HCFwLgAR+1EbwVhLUY+WZUL8NuciMzdcwpV9cvvJpkB9u+qT4LXESoMKXxU49dUHdg 9v1cCEP2RNnXzFbya5V+0N3WXxCI9op/s+q3UOne06TxVRZchRJum40BhQ5EQTKwmOF2 rnRJJd0pgfm4Yi2Tky7nQbfnyPgTGUzuVA/qFuluMRQiQ/0E24P4XaYUtrqAN+H1znry aN+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=Pe7UPPWi3fWc5p9PXNyVh3UbOcCqQUHgiqZUh4MSeBc=; b=Ae1bCmOoTAT5sgIrDN1E2Xqn0+L7iBRy9g5hM68KmcTE9aMr1lJCpW76XFHCyrpxsy 2Gcn4083XnRBFcRkvCDDWIAIhISrTTiy4dA8CI+UByh3V4yvXONOFZt9ANghymeWM7Kg jubwy+I3MPJs55ee8o22r3JPRTyoWuL+vjQ3ewhUG4jxsMwSviQ0sXOQCxK7MZAnhpKF xcuD5zQToN2RzaM1LAKYs8aQRS65VA3WoKRSJtXFw3u1Hi6JVOyihYenxgrL++KuPhob O5NCxif+vThVp2wYOu5DJ05qzweHdKzO0xgbiwMR4E0mYneWvcEsDGb1s3XBJHv+IObB JN9g== X-Gm-Message-State: AIkVDXIQ6dP1ItJQ0qf0yleFpY8yw6h3zwmEDwbfRx2dQDm0VLTcCorCKjQEmvx8/MJauXqv X-Received: by 10.55.212.157 with SMTP id s29mr64956206qks.240.1483630485202; Thu, 05 Jan 2017 07:34:45 -0800 (PST) Received: from DESKTOP8OQ9GIB ([172.85.41.102]) by smtp.gmail.com with ESMTPSA id z29sm48457469qtz.16.2017.01.05.07.34.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 07:34:43 -0800 (PST) From: "Ritesh Mukherjee" To: Subject: soliciting feedback on draft-abilash-quic-network Date: Thu, 5 Jan 2017 10:34:40 -0500 Message-ID: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021E_01D2673F.52B96CD0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJnaJAo7EFh+AryQuCJjvpLcGn68Q== Content-Language: en-us Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:34:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_021E_01D2673F.52B96CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Team, We recently published draft-abilash-quic-network-00 which proposes a change to the QUIC protocol header that will allow network elements to prioritize streams in QUIC packets, divert high priority streams to low loss paths, and adjust packet pacing on a per stream basis. We have already received some very positive comments from some members but wanted to solicit feedback from the larger community. Please provide your comments/feedback/recommendations as necessary: URL: https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 Thank you in advance! Ritesh ------=_NextPart_000_021E_01D2673F.52B96CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Team,

 

We = recently published draft-abilash-quic-network-00 which proposes a change = to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary: =

 

URL:        =     https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00= .txt

Htmlized:       https:= //tools.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in = advance!

 

Ritesh

 

------=_NextPart_000_021E_01D2673F.52B96CD0-- From nobody Thu Jan 5 08:02: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 2B215129B5D for ; Thu, 5 Jan 2017 08:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VnrHcKPBS_G for ; Thu, 5 Jan 2017 08:02:50 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1E312949F for ; Thu, 5 Jan 2017 08:02:50 -0800 (PST) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 957563A021 for ; Thu, 5 Jan 2017 11:02:49 -0500 (EST) Received: by mail-qk0-f173.google.com with SMTP id s140so24195735qke.0 for ; Thu, 05 Jan 2017 08:02:49 -0800 (PST) X-Gm-Message-State: AIkVDXIMVQdtibqphD7rJ3ecqIOUl9rTwVFsopEyLoXFlV9fjnjw3s+wNwAYujy3kNLzqBcGep6RoI+i5JGM8Q== X-Received: by 10.55.18.85 with SMTP id c82mr8615846qkh.93.1483632169229; Thu, 05 Jan 2017 08:02:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.157.12 with HTTP; Thu, 5 Jan 2017 08:02:48 -0800 (PST) In-Reply-To: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> From: Patrick McManus Date: Thu, 5 Jan 2017 11:02:48 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Ritesh Mukherjee Content-Type: multipart/alternative; boundary=001a1146b9706d653b05455b08eb Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:02:52 -0000 --001a1146b9706d653b05455b08eb Content-Type: text/plain; charset=UTF-8 Ritesh - thanks for taking the time to write your thoughts down and sharing them. The draft calls for removing encryption of the stream ID and also adding a priority system at the transport level that's less expressive than the h2 one quic has to carry - (also unencrypted). The quic charter calls for " a UDP-based, stream-multiplexing, encrypted transport protocol". and "provide confidentiality [..] of both application data and QUIC header.". Further, draft-abilash's security considerations are effectively empty, which makes me doubt things like traffic analysis, etc have been considered. This doesn't sound like the mentioned draft should be used for changes in the protocol, though it may provide useful input to the applicability and manageability statement. -Patrick On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee < rmukherjee@128technology.com> wrote: > Hi Team, > > > > We recently published draft-abilash-quic-network-00 which proposes a > change to the QUIC protocol header that will allow network elements to > prioritize streams in QUIC packets, divert high priority streams to low > loss paths, and adjust packet pacing on a per stream basis. We have already > received some very positive comments from some members but wanted to > solicit feedback from the larger community. Please provide your > comments/feedback/recommendations as necessary: > > > > URL: https://www.ietf.org/internet-drafts/draft-abilash-quic- > network-00.txt > > Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 > > > > Thank you in advance! > > > > Ritesh > > > --001a1146b9706d653b05455b08eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ritesh - thanks for taking the time to writ= e your thoughts down and sharing them.

The draft calls fo= r removing encryption of the stream ID and also adding a priority system at= the transport level that's less expressive than the h2 one quic has to= carry - (also unencrypted).

The quic charter calls for "= a UDP-based, stream-multiplexing, encrypted transport protocol". and = "provide confidentiality [..] of both application data and QUIC header= .".

Further, draft-abilash's security considerations = are effectively empty, which makes me doubt things like traffic analysis, e= tc have been considered.

This doesn't sound like the mentioned = draft should be used for changes in the protocol, though it may provide use= ful input to the applicability and manageability statement.

-P= atrick


On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukher= jee <rmukherjee@128technology.com> wrote:

Hi Team,

=C2=A0

We recently pub= lished draft-abilash-quic-network-00 which proposes a change to the QUIC pr= otocol header that will allow network elements to prioritize streams in QUI= C packets, divert high priority streams to low loss paths, and adjust packe= t pacing on a per stream basis. We have already received some very positive= comments from some members but wanted to solicit feedback from the larger = community. Please provide your comments/feedback/recommendations as ne= cessary:

=C2=A0

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-abi= lash-quic-network-00.txt

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-abilash-quic-network-00

=C2=A0

= Thank you in advan= ce!

= =C2=A0

Ritesh

=C2= =A0


--001a1146b9706d653b05455b08eb-- From nobody Thu Jan 5 08:50: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 7D128129496 for ; Thu, 5 Jan 2017 08:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 XNU5uzFE3vOD for ; Thu, 5 Jan 2017 08:50:42 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 70139129593 for ; Thu, 5 Jan 2017 08:50:33 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id c47so524151175qtc.2 for ; Thu, 05 Jan 2017 08:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=2swSpOR1AeI1Wg7KuWw6lJhofB1YEfzhFKx4iuXrbAg=; b=y8Q3l11+sQ0PEDidBJai8mtSvcFK8HoGWQ+40E0S6YpjveMDYFHOVlqeMfxb5Ad8Sg Uj0U3bDTHxm9CHji9wHoU+yXC1phIsUgHa8shOgTFk+RrKozqDKkIj351Kg0+dHP/pzN L7O/bRjCjcigWX4bF5vK+0Sp0DuQGu3Kg7B/JRBSpQc6i/Rdvo1lWdGWIlUn83CJzyKM sps7tSiaQxOWCPVkYGe2fFHZwZhJEOK6EnV/YVSNqPGL0Xjo3Ewkfd0VJpOVO/Ly+7fx magK7SS7AgKEFwJsFnZlmMyT4/C72sHEkZAY2nGVlVQ7BcX8ZNQLYpN2B6YyElbZUJPk vB4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=2swSpOR1AeI1Wg7KuWw6lJhofB1YEfzhFKx4iuXrbAg=; b=AfoKkN/uOWZ6JpcZaWe2L+CQ3xyxGoLjLCT69RuU1IPDB58VbtKaXYDISCguOfot6u uV0rkvbjBlEmvnBX+6HTbnt2H1EDs3ZRxeppv/amhg7funUuWLiJUZyugl/TtVRLy7mJ 6voZrKqt9+MsrZIjavtUSmCIhB2d+JFotuLLWQ/9PmqnzZvSPA/fCNmsp4bhiZbqh3MM min7NsLL+sGRq7zXVlbLRG45wv4fMhJ6+xhfj8dVcE5wZar80BTpF/RM4v3yK1mzXcHj 8ZBwEGPll10Keb5ugrTR+FSGX8hdGW42cc7sC2YP4ydKbZdD02qA34ozG3z8hdY2eQ1g qL9g== X-Gm-Message-State: AIkVDXJWuO0zRwNGubfrMrePLCWxjEhXNdfAZWq0Iy4xxfpLDTB/lMGTn0DNqBFrfFtKncAU X-Received: by 10.237.37.77 with SMTP id w13mr74922790qtc.197.1483635017114; Thu, 05 Jan 2017 08:50:17 -0800 (PST) Received: from DESKTOP8OQ9GIB ([172.85.41.102]) by smtp.gmail.com with ESMTPSA id m184sm30363740qkb.1.2017.01.05.08.50.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 08:50:16 -0800 (PST) From: "Ritesh Mukherjee" To: "'Patrick McManus'" References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> In-Reply-To: Subject: RE: soliciting feedback on draft-abilash-quic-network Date: Thu, 5 Jan 2017 11:50:13 -0500 Message-ID: <02a401d26773$c97fedb0$5c7fc910$@128technology.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A5_01D26749.E0AB1E30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHdW5MPCBQI3E7Yzcbczzhdf2tIqgIYsZyWoQNe0RA= Content-Language: en-us Archived-At: Cc: 'IETF QUIC WG' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:50:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02A5_01D26749.E0AB1E30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Patrick, =20 Please see inline=E2=80=A6.. =20 Ritesh =20 =20 From: Patrick McManus [mailto:pmcmanus@mozilla.com]=20 Sent: Thursday, January 5, 2017 11:03 AM To: Ritesh Mukherjee Cc: IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network =20 Ritesh - thanks for taking the time to write your thoughts down and = sharing them. The draft calls for removing encryption of the stream ID and also adding = a priority system at the transport level that's less expressive than the = h2 one quic has to carry - (also unencrypted). [Ritesh] The stream ID and priority are authenticated. Yes =E2=80=93 = they need to be unencrypted for the network elements to optimize = performance. The quic charter calls for " a UDP-based, stream-multiplexing, encrypted = transport protocol". and "provide confidentiality [..] of both = application data and QUIC header.". [Ritesh] The entire statement says =E2=80=9Cdescribe how those keys are = used to provide confidentiality and integrity protection of both = application data and QUIC headers.=E2=80=9D. The charter does not = mandate not exposing any element of the QUIC header even if it would = improve performance. Further, draft-abilash's security considerations are effectively empty, = which makes me doubt things like traffic analysis, etc have been = considered. [Ritesh] Agreed. It is work in progress. We have done testing and = analysis. We will update it in the next iteration and suggestions are = always welcome. =20 This doesn't sound like the mentioned draft should be used for changes = in the protocol, though it may provide useful input to the applicability = and manageability statement. [Ritesh] We are open to all suggestions. Our current thinking is that = this should be an option in future implementations. =20 -Patrick =20 =20 On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee = > = wrote: Hi Team, =20 We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary:=20 =20 URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 =20 Thank you in advance! =20 Ritesh =20 =20 ------=_NextPart_000_02A5_01D26749.E0AB1E30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Patrick,

 

Please see = inline=E2=80=A6..

 

Ritesh

 

 

From:<= /b> = Patrick McManus [mailto:pmcmanus@mozilla.com]
Sent: Thursday, = January 5, 2017 11:03 AM
To: Ritesh Mukherjee = <rmukherjee@128technology.com>
Cc: IETF QUIC WG = <quic@ietf.org>
Subject: Re: soliciting feedback on = draft-abilash-quic-network

 

Ritesh - thanks for taking the time to write your = thoughts down and sharing them.


The draft calls for = removing encryption of the stream ID and also adding a priority system = at the transport level that's less expressive than the h2 one quic has = to carry - (also unencrypted).

[Ritesh] The stream ID and priority are = authenticated. Yes =E2=80=93 they need to be unencrypted for the network = elements to optimize performance.

The quic charter calls = for " a UDP-based, stream-multiplexing, encrypted transport = protocol". and "provide confidentiality [..] of both = application data and QUIC header.".

[Ritesh] The entire statement says = =E2=80=9Cdescribe how those keys are used to provide confidentiality and = integrity protection of both application data and QUIC = headers.=E2=80=9D. The charter does not mandate not exposing any element = of the QUIC header even if it would improve = performance.

Further, draft-abilash's security = considerations are effectively empty, which makes me doubt things like = traffic analysis, etc have been considered.

[Ritesh] Agreed. It is work in progress. We have = done testing and analysis. We will update it in the next iteration and = suggestions are always welcome.=C2=A0


This doesn't sound like the mentioned = draft should be used for changes in the protocol, though it may provide = useful input to the applicability and manageability = statement.

[Ritesh] We are open to all suggestions. Our = current thinking is that this should be an option in future = implementations.=C2=A0

-Patrick

 

 

On Thu, = Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee <rmukherjee@128technology.com> = wrote:

Hi = Team,

 

We recently published = draft-abilash-quic-network-00 which proposes a change to the QUIC = protocol header that will allow network elements to prioritize streams = in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received = some very positive comments from some members but wanted to solicit = feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary:

 

URL:    &nbs= p;       https://www.ietf.org/internet-drafts/draft-abilash-quic= -network-00.txt

Htmlized:    = ;   https://tools.ietf.org/html/draft-abilash-quic-network-= 00

 

Thank you in = advance!

 

Ritesh

 

 

------=_NextPart_000_02A5_01D26749.E0AB1E30-- From nobody Thu Jan 5 10:20: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 379A1129BAF for ; Thu, 5 Jan 2017 10:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 4GCyy2umwxpN for ; Thu, 5 Jan 2017 10:20:10 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C015129BB1 for ; Thu, 5 Jan 2017 10:20:10 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n21so441306659qka.3 for ; Thu, 05 Jan 2017 10:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UaaOQ5QO7So8+0U4cHB/sR2fAxoXxSb9I6crLrdlhnI=; b=MIRu2oM0Sxv5wtdsOZYRu3DaGQ859YYrsqxq/p0bZXdhUowBdFA3UFkVmEz1Pd65o7 kyHLMqXBTosITxwGsrLeWGkTEZpHMzxdMWX3RCaYAyyB+G/ywokXSgxgxuIAIND7OhqH kezdblFI2v2VEWAU3dYkWcwAuZDLvbenZD2IqU7T9ij5RCSBd+K2mZ4rqGkU7gJtFmIj KoM2ZsMw8j1Pb3Cc+aJs4izHzBMlqcOHwP1mEX2SvPmNUnIqe1W7wQBEYQdby5sGXTwX 9UkDWZhGbLQ8T7hlLqnQkOXcdpnJ91me9eyebsiNtI4LscyJnAA3dRIvavxCKmhC/bcC jEMg== 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 :message-id:references:to; bh=UaaOQ5QO7So8+0U4cHB/sR2fAxoXxSb9I6crLrdlhnI=; b=MwEzu07MfmM3R1h2EiNw8HYzosXqIRm7+yOcLztBe+pne2LVGvoem34rjB0n2GLNGX VBrZjjLzP7oaV6pfMgXRnmZWKegiOOAGVqhdfj4jHegNJsn/flq6+fARvLNtZiBI4yIc O5RWZJ/lHrAExmJ+3WiqRMorciN443LwRj5hBzW1MM5SAD74xXF3f4i0VtWeqxIFkzVt f1P2p3eJYNhi2s2Zrb/VAfkK7uh9hd0KjioFokim1TO7r3meQg7W9HOn6B18K8E7GbAs s+vU2laPo9NbU/0PO9t8wNNtwQNCjUvm7GK//CgFB7vicNuXTWxjCLAAlKundYmQBPx0 y36g== X-Gm-Message-State: AIkVDXJndIAORwsmvGLd3rOCsZBRJg15DU2gMsfxdOzRiyVhwvHXNhTHcj+Wdki6ANaglVNE X-Received: by 10.55.129.4 with SMTP id c4mr69780922qkd.14.1483640409571; Thu, 05 Jan 2017 10:20:09 -0800 (PST) Received: from [10.0.2.25] ([172.85.50.34]) by smtp.gmail.com with ESMTPSA id b195sm275710qkg.27.2017.01.05.10.20.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Jan 2017 10:20:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F0FF9DD5-2F9C-4579-93B3-5A5DC1D69F09" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: <02a401d26773$c97fedb0$5c7fc910$@128technology.com> Date: Thu, 5 Jan 2017 13:20:08 -0500 Message-Id: References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <02a401d26773$c97fedb0$5c7fc910$@128technology.com> To: Ritesh Mukherjee X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG , Patrick McManus X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 18:20:12 -0000 --Apple-Mail=_F0FF9DD5-2F9C-4579-93B3-5A5DC1D69F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Patrick, More replies inline > On Jan 5, 2017, at 11:50 AM, Ritesh Mukherjee = wrote: >=20 > Hi Patrick, > =20 > Please see inline=E2=80=A6.. > =20 > Ritesh > =20 > =C2=A0 <> > From: Patrick McManus [mailto:pmcmanus@mozilla.com = ]=20 > Sent: Thursday, January 5, 2017 11:03 AM > To: Ritesh Mukherjee > > Cc: IETF QUIC WG > > Subject: Re: soliciting feedback on draft-abilash-quic-network > =20 > Ritesh - thanks for taking the time to write your thoughts down and = sharing them. >=20 > The draft calls for removing encryption of the stream ID and also = adding a priority system at the transport level that's less expressive = than the h2 one quic has to carry - (also unencrypted). >=20 > [Ritesh] The stream ID and priority are authenticated. Yes =E2=80=93 = they need to be unencrypted for the network elements to optimize = performance. >=20 > The quic charter calls for " a UDP-based, stream-multiplexing, = encrypted transport protocol". and "provide confidentiality [..] of both = application data and QUIC header.". >=20 > [Ritesh] The entire statement says =E2=80=9Cdescribe how those keys = are used to provide confidentiality and integrity protection of both = application data and QUIC headers.=E2=80=9D. The charter does not = mandate not exposing any element of the QUIC header even if it would = improve performance. >=20 We would like to understand your concerns as to why this would = be a problem.. The draft calls for exposing some fields in the header so = that QUIC can benefit from the network. These could be made optional for = clients which do not want to avail any network performance enhancements. > Further, draft-abilash's security considerations are effectively = empty, which makes me doubt things like traffic analysis, etc have been = considered >=20 >=20 >=20 > [Ritesh] Agreed. It is work in progress. We have done testing and = analysis. We will update it in the next iteration and suggestions are = always welcome. =20 >=20 Yes. We will update the draft with more details. Please let us = know if there are some specific cases you would like us to address. >=20 > This doesn't sound like the mentioned draft should be used for changes = in the protocol, though it may provide useful input to the applicability = and manageability statement. >=20 Please let us know your concerns and we can work through them. = We strongly feel this will be useful to prioritize QUIC traffic more = effectively in the network elements. This would be a way to bring = application layer information into the network layer for more = intelligent traffic engineering and prioritization. Thanks, Abilash > [Ritesh] We are open to all suggestions. Our current thinking is that = this should be an option in future implementations. =20 >=20 > -Patrick >=20 > =20 > =20 > On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee = > = wrote: >> Hi Team, >> =20 >> We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary:=20 >> =20 >>=20 >> URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt = >> Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 = >> =20 >> Thank you in advance! >> =20 >> Ritesh >> =20 >=20 > =20 --Apple-Mail=_F0FF9DD5-2F9C-4579-93B3-5A5DC1D69F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Patrick,

More replies inline <amenon>

On = Jan 5, 2017, at 11:50 AM, Ritesh Mukherjee <rmukherjee@128technology.com> wrote:

Hi = Patrick,
 
Please see inline=E2=80=A6..<= o:p class=3D"">
 
Ritesh
 
 
From: Patrick McManus [mailto:pmcmanus@mozilla.com] 
Sent: Thursday, January 5, 2017 = 11:03 AM
To: Ritesh Mukherjee <rmukherjee@128technology.com>
Cc: IETF = QUIC WG <quic@ietf.org>
Subject: Re: soliciting feedback on = draft-abilash-quic-network
 
Ritesh - thanks for taking the time to = write your thoughts down and sharing them.


The draft calls for removing encryption = of the stream ID and also adding a priority system at the transport = level that's less expressive than the h2 one quic has to carry - (also = unencrypted).

[Ritesh] The stream ID and = priority are authenticated. Yes =E2=80=93 they need to be unencrypted = for the network elements to optimize performance.

The quic charter calls for " a UDP-based, stream-multiplexing, = encrypted transport protocol". and "provide confidentiality [..] of both = application data and QUIC header.".

[Ritesh] The entire statement says =E2=80=9Cdescribe how = those keys are used to provide confidentiality and integrity protection = of both application data and QUIC headers.=E2=80=9D. The charter does = not mandate not exposing any element of the QUIC header even if it would = improve = performance.

<amenon> We would like to understand your = concerns as to why this would be a problem.. The draft calls for = exposing some fields in the header so that QUIC can benefit from the = network. These could be made optional for clients which do not want to = avail any network performance enhancements.

Further, draft-abilash's security considerations are = effectively empty, which makes me doubt things like traffic analysis, = etc have been considered



[Ritesh] Agreed. It is work in progress. = We have done testing and analysis. We will update it in the next = iteration and suggestions are always welcome.  

=

<amenon> Yes. We = will update the draft with more details. Please let us know if there are = some specific cases you would like us to address.


This = doesn't sound like the mentioned draft should be used for changes in the = protocol, though it may provide useful input to the applicability and = manageability = statement.

<amenon> = Please let us know your concerns and we can work through them. We = strongly feel this will be useful to prioritize QUIC traffic more = effectively in the network elements. This would be a way to bring = application layer information into the network layer for more = intelligent traffic engineering and prioritization.

Thanks,
Abilash

[Ritesh] We are open to = all suggestions. Our current thinking is that this should be an option = in future implementations.  

-Patrick

 
 
On Thu, Jan 5, 2017 = at 10:34 AM, Ritesh Mukherjee <rmukherjee@128technology.com> wrote:
Hi = Team,
 
We recently published draft-abilash-quic-network-00 which = proposes a change to the QUIC protocol header that will allow network = elements to prioritize streams in QUIC packets, divert high priority = streams to low loss paths, and adjust packet pacing on a per stream = basis. We have already received some very positive comments from some = members but wanted to solicit feedback from the larger community. Please = provide your comments/feedback/recommendations as necessary: 

 

URL:          &n= bsp; https://www.ietf.org/internet-drafts/draft-abilash-quic-network= -00.txt

Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

 
Thank you in = advance!
 
Ritesh
 
 

= --Apple-Mail=_F0FF9DD5-2F9C-4579-93B3-5A5DC1D69F09-- From nobody Thu Jan 5 11:42: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 18C0C129404 for ; Thu, 5 Jan 2017 11:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg4kMNiZpMmJ for ; Thu, 5 Jan 2017 11:42:30 -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 3847B129634 for ; Thu, 5 Jan 2017 11:42:30 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cPDvg-0001XO-6G for quic@ietf.org; Thu, 05 Jan 2017 20:42:28 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cPDuI-00043c-LK for quic@ietf.org; Thu, 05 Jan 2017 14:42:26 -0500 Received: (qmail 4485 invoked from network); 5 Jan 2017 19:41:01 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.38.210]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Jan 2017 19:41:00 -0000 From: "Christian Huitema" To: "'Ritesh Mukherjee'" , References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> In-Reply-To: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> Date: Thu, 5 Jan 2017 11:40:55 -0800 Message-ID: <021b01d2678b$a2b39980$e81acc80$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHdW5MPCBQI3E7Yzcbczzhdf2tIqqEUWV1g Subject: RE: soliciting feedback on draft-abilash-quic-network X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.25) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrNT1GwJlgpldxvqPpB5P7VRcOb18WfxGyg6Om6u4YYm6wWxh8gz+dygMeV J/szENk5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQxQRCdMNhge1Unb77YyuZq5JYjY7JiqnQoO7Qs6XVPt8RBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f3u07h1Ar0asfEVCjJZw/E01 aDvSI66S1J0VQ44N+76FCIPXOMRjWUkAhwUJkkvSfamxVEE6gtF+B/lEIPzms74rHdmmurdkSlp8 bL7MuNSeJ6fVbIdD0RyyBL+RsQXLIsIclqURQOfTUwDe+Ri01fK//LgD8r/EmKnkLuRbKmSGxlp0 rzUdrgqjB31bCd9Lg/Y4ocfmWv3Fe9Iziczdq+A= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:42:32 -0000 On Thursday, January 5, 2017 7:35 AM, Ritesh Mukherjee wrote: > We recently published draft-abilash-quic-network-00 which proposes a change=20 > to the QUIC protocol header that will allow network elements to = prioritize streams > in QUIC packets, divert high priority streams to low loss paths, and adjust packet=20 > pacing on a per stream basis. We have already received some very = positive comments > from some members but wanted to solicit feedback from the larger community. Please > provide your comments/feedback/recommendations as necessary:=20 > > URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt > Htmlized:=A0=A0=A0=A0=A0=A0 = https://tools.ietf.org/html/draft-abilash-quic-network-00 I have read your draft, and do not believe it should be adopted by the working group at this point. First, we should be extremely cautious = about adding any information in the public header, because of well documented issues such as middlebox interference or ossification. In particular, = there is a long history of middle boxes doing strange things with anything = that pretends to be a priority field. Also, the connection control pretty = much assumes a single flow of packets forwarded with equal priorities. You = just cannot assume the interaction between priorities and error connection = would be beneficial.=20 The quoted motivation for your draft is a research paper published last = May, "How quick is QUIC" (https://www.researchgate.net/publication/302585207_How_quick_is_QUIC). = The simulations reported in this paper show QUIC being generally more = efficient than HTTP or SPDY, except in one set of conditions: high bandwidth, = large proportion of large objects, and very low packet loss rate. It is = unclear whether that conclusion depends on the QUIC protocol, or on = implementation parameters used in the simulation. The authors attribute it to "the = packet pacing mechanism in QUIC", which would be too conservative and would = unduly slow down the transmissions.=20 Your draft quotes that same study as [MEG2016], but comes with its own explanation of the issue, "This is because QUIC is an end to end = protocol and provides no means for the intermediate network elements to = contribute to QUIC improvements." There is no mention of such explanation in = [MEG2016], which leads me to believe that your statement is just a personal = opinion, not based on any published study.=20 In short, I believe that the technical solution that you propose is not justified by any study. It would add complexity in the protocol without = any proven benefit. It would risk serious interoperability issues, and would greatly increase the risk of middle box interference. I don't see why = the WG would work on that. -- Christian Huitema From nobody Thu Jan 5 11:57: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 C81FD129640 for ; Thu, 5 Jan 2017 11:57:41 -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 iPTw3HNWsRR1 for ; Thu, 5 Jan 2017 11:57:39 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BF1129604 for ; Thu, 5 Jan 2017 11:57:39 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s140so31243935qke.0 for ; Thu, 05 Jan 2017 11:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nu86b+4vlBvu6kkaF6wITqZsLytGu9/dn40rSe+FOx8=; b=n5hbrr1CetS+zojTiKRLAUnrIgkP2Sj40vpxsNK2ZJZd+kYdeMvoVhQVynm2paZSvH q9lmBE10xob4agUuO5WzFbluUjDEq+Zfp182wWzhTZgnHlZHd+yUZkAozVz/UKpAttdd PqnzRSCGj5pyfkAYqok+KsgA3b+63APtUeh6gXcYJxh5OcKKF92/K1GEVTt8G+Oi2IAO UXzepcHbQIM2W+k7VsGEZGCfsNaDW90AHAnc5h+ZFvApTptd23XxgU1+A56Qk0EN41q5 KzbkUYocfrPzmPAcBUulLGLXuKR2IHzjsdxjTF0J7l3qRr0MbYx4cHcmeur0zBOMe5KP 87sA== 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=nu86b+4vlBvu6kkaF6wITqZsLytGu9/dn40rSe+FOx8=; b=ZDEFOpFqFGoegImP4ReK7cr+5oFSFy3l+9qmVO0Vx9FxxMQC/fwV5aO5AJNGZEOKah hawlDP5rbNUhaOzSuxA4cYh5keD0u21J/WG9XchEfXEs/I7KXngdJCQ9br1JBxMJSCKc GlObtpR4VmbXjFEU4QjSpoNa5slLHzyJyMMEJgpEiB591cFRRt8HO1q9d1uyFiVjkkUH xB6ICGYyzk8bDdkCD6KqYP11DTp0v2LcKpvNB4ReKaY3lVedT110NHAoSX3kOjjvRUwf Du+InChbY3KROixucA2/ZATxLd/kb+d3E2JQ50MIkU85fU+cG/6ve2mY1WY1RgD83KIA xZng== X-Gm-Message-State: AIkVDXK87ac/1uLEQeY5SGnDqoqQYTveZRpFjo5dy2Npz7xk8VO3ZJBYFEcpNtmRCJZ48K7MIv8FAUf35398VQ== X-Received: by 10.55.137.197 with SMTP id l188mr70861629qkd.94.1483646258754; Thu, 05 Jan 2017 11:57:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.182.66 with HTTP; Thu, 5 Jan 2017 11:57:08 -0800 (PST) In-Reply-To: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> From: Ted Hardie Date: Thu, 5 Jan 2017 11:57:08 -0800 Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Ritesh Mukherjee Content-Type: multipart/alternative; boundary=94eb2c072e7239ba3905455e504c Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:57:42 -0000 --94eb2c072e7239ba3905455e504c Content-Type: text/plain; charset=UTF-8 Howdy, Forgive the top posting, but this seems to be a bit of meta-question. If I read your draft correctly, you are suggesting that QUIC expose stream identifiers and associate them with a priority, so that on-path devices may move certain streams onto higher priority paths or otherwise give variable quality of service. For this to work correctly, though, the basic aim of multiplexing seems to be changed as you could not multiplex streams into the same packet, even if they have the same desired network treatment. At that level of isolation, independent QUIC connections may suit your use cases just as well (if, indeed, you would choose QUIC at all). If that is the required level of independence, why does opening different connections not work as well? It's also not clear why you need that level of independence. At the very least, your description makes it seem that you could multiplex streams whose desired network treatment is the same. And, if you did multiplex streams with the same desired network treatment, there seems to be no need at all to expose the stream identifiers (after all, you might have more than one stream in a packet). Instead, you would only need to expose the desired network treatment for a specific packet. Why is that not enough to meet the need and why, if that is the case, would differentiated DSCP markings not meet your needs? On the latter case, there was good bit of discussion on how well multiple DSCP markings on a single 5-tuple would work in the context of WEBRTC; if you have not read RFC 7657, I would suggest doing so, along with draft-ietf-tsvwg-rtcweb-qos. Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect many of the lessons learned would apply to your efforts, whether you used DSCP or a different marking. regards, Ted On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < rmukherjee@128technology.com> wrote: > Hi Team, > > > > We recently published draft-abilash-quic-network-00 which proposes a > change to the QUIC protocol header that will allow network elements to > prioritize streams in QUIC packets, divert high priority streams to low > loss paths, and adjust packet pacing on a per stream basis. We have already > received some very positive comments from some members but wanted to > solicit feedback from the larger community. Please provide your > comments/feedback/recommendations as necessary: > > > > URL: https://www.ietf.org/internet- > drafts/draft-abilash-quic-network-00.txt > > Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 > > > > Thank you in advance! > > > > Ritesh > > > --94eb2c072e7239ba3905455e504c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Forgive the top posting= , but this seems to be a bit of meta-question.=C2=A0 If I read your draft c= orrectly, you are suggesting that QUIC expose stream identifiers and associ= ate them with a priority, so that on-path devices may move certain streams = onto higher priority paths or otherwise give variable quality of service.
For this to work correctly, though, the basic aim of multiplexi= ng seems to be changed as you could not multiplex streams into the same pac= ket, even if they have the same desired network treatment.=C2=A0 At that le= vel of isolation, independent QUIC connections may suit your use cases just= as well (if, indeed, you would choose QUIC at all).=C2=A0 If that is the r= equired level of independence, why does opening different connections not w= ork as well?

It's also not clear why you need that level of inde= pendence. At the very least, your description makes it seem that you could = multiplex streams whose desired network treatment is the same.=C2=A0 And, i= f you did multiplex streams with the same desired network treatment, there = seems to be no need at all to expose the stream identifiers (after all, you= might have more than one stream in a packet).=C2=A0 Instead, you would onl= y need to expose the desired network treatment for a specific packet.=C2=A0= Why is that not enough to meet the need and why, if that is the case, woul= d differentiated DSCP markings not meet your needs?

On th= e latter case, there was good bit of discussion on how well multiple DSCP m= arkings on a single 5-tuple would work in the context of WEBRTC; if you hav= e not read RFC 7657, I would suggest doing so, along with draft-ietf-tsvwg-= rtcweb-qos.=C2=A0 Though pointing primarily at RTP flows multiplexed using = BUNDLE, I suspect many of the lessons learned would apply to your efforts, = whether you used DSCP or a different marking.

regards,
Ted



On Thu, Jan 5, 2017 at 7= :34 AM, Ritesh Mukherjee <rmukherjee@128technology.com><= /span> wrote:

Hi Team,

=C2=A0<= /u>

We recently published draft-abilash-quic-network-00 whic= h proposes a change to the QUIC protocol header that will allow network ele= ments to prioritize streams in QUIC packets, divert high priority streams t= o low loss paths, and adjust packet pacing on a per stream basis. We have a= lready received some very positive comments from some members but wanted to= solicit feedback from the larger community. Please provide your comments/f= eedback/recommendations as necessary:

=C2=A0

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Htmli= zed:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.or= g/html/draft-abilash-quic-network-00

= =C2=A0

Thank you in advance!

=C2=A0

Ritesh=

=C2=A0


--94eb2c072e7239ba3905455e504c-- From nobody Thu Jan 5 12:31: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 DB4CE129574 for ; Thu, 5 Jan 2017 12:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yauOe4YyBAYu for ; Thu, 5 Jan 2017 12:31:24 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 03F1E12947B for ; Thu, 5 Jan 2017 12:31:23 -0800 (PST) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0EF923A021 for ; Thu, 5 Jan 2017 15:31:23 -0500 (EST) Received: by mail-qt0-f180.google.com with SMTP id l7so12388596qtd.1 for ; Thu, 05 Jan 2017 12:31:23 -0800 (PST) X-Gm-Message-State: AIkVDXIPfzzBB7tBx86mIS7adXCI2171F1mNd6Y2IBp0Ou3WjN35xvBogAPCiepVSQXp70kWy3IK6kdxzxauwQ== X-Received: by 10.200.51.6 with SMTP id t6mr58200321qta.75.1483648282809; Thu, 05 Jan 2017 12:31:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.157.12 with HTTP; Thu, 5 Jan 2017 12:31:22 -0800 (PST) In-Reply-To: References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <02a401d26773$c97fedb0$5c7fc910$@128technology.com> From: Patrick McManus Date: Thu, 5 Jan 2017 15:31:22 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Abilash Menon Content-Type: multipart/alternative; boundary=001a1145bf90de693205455ec821 Archived-At: Cc: Ritesh Mukherjee , IETF QUIC WG , Patrick McManus X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 20:31:27 -0000 --001a1145bf90de693205455ec821 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey All, My high level comment is that (from the abstract of the transport ID) "QUIC encrypts most of its headers, thereby limiting protocol evolution to QUIC endpoints only. Therefore, middleboxes, in large part, are not required to be updated as new protocol versions are deployed". unencrypting data in order to have middleboxes be updated for new protocol versions (and their options!) is really an anti-goal of this work. This is for both protocol evolution and application confidentiality. This is a strong end to end design decision - if you think the value of a transport protocol instead comes from network signaling you're going to disagree with a number of design decisions. The open questions are often about how _more_ confidentiality and integrity can be created (i.e. is it feasible to make the connection identifier less trackable, and how a public reset can be made less public (or if its even needed at all)) - the public stream id proposal blows against that headwind. Others have made interesting comments about the relationship between frames and packets and there are at least 2 github issues open on priority and retransmission - Christian also makes a good comment in this thread about congestion control and its embedded assumptions. Making these elements opaque to the network lets the transport protocol come to a consistent internal resolution to these questions without depending on path behavior which is aligned with the goal in my first paragraph. hth explain my thoughts. Again, thanks for taking the time to write it down. I know that can feel thankless, but it really helps everyone understand crisply what is being discussed and I sincerely appreciate it. -Patrick On Thu, Jan 5, 2017 at 1:20 PM, Abilash Menon wrote: > Patrick, > > More replies inline > > On Jan 5, 2017, at 11:50 AM, Ritesh Mukherjee < > rmukherjee@128technology.com> wrote: > > Hi Patrick, > > Please see inline=E2=80=A6.. > > Ritesh > > > *From:* Patrick McManus [mailto:pmcmanus@mozilla.com > ] > *Sent:* Thursday, January 5, 2017 11:03 AM > *To:* Ritesh Mukherjee > *Cc:* IETF QUIC WG > *Subject:* Re: soliciting feedback on draft-abilash-quic-network > > Ritesh - thanks for taking the time to write your thoughts down and > sharing them. > > > The draft calls for removing encryption of the stream ID and also adding = a > priority system at the transport level that's less expressive than the h2 > one quic has to carry - (also unencrypted). > > [Ritesh] The stream ID and priority are authenticated. Yes =E2=80=93 they= need to > be unencrypted for the network elements to optimize performance. > > The quic charter calls for " a UDP-based, stream-multiplexing, encrypted > transport protocol". and "provide confidentiality [..] of both applicatio= n > data and QUIC header.". > > [Ritesh] The entire statement says =E2=80=9Cdescribe how those keys are u= sed to > provide confidentiality and integrity protection of both application data > and QUIC headers.=E2=80=9D. The charter does not mandate not exposing any= element > of the QUIC header even if it would improve performance. > > > We would like to understand your concerns as to why this would b= e > a problem.. The draft calls for exposing some fields in the header so tha= t > QUIC can benefit from the network. These could be made optional for clien= ts > which do not want to avail any network performance enhancements. > > Further, draft-abilash's security considerations are effectively empty, > which makes me doubt things like traffic analysis, etc have been consider= ed > > > [Ritesh] Agreed. It is work in progress. We have done testing and > analysis. We will update it in the next iteration and suggestions are > always welcome. > > > Yes. We will update the draft with more details. Please let us > know if there are some specific cases you would like us to address. > > > This doesn't sound like the mentioned draft should be used for changes in > the protocol, though it may provide useful input to the applicability and > manageability statement. > > Please let us know your concerns and we can work through them. W= e > strongly feel this will be useful to prioritize QUIC traffic more > effectively in the network elements. This would be a way to bring > application layer information into the network layer for more intelligent > traffic engineering and prioritization. > > Thanks, > Abilash > > [Ritesh] We are open to all suggestions. Our current thinking is that thi= s > should be an option in future implementations. > > -Patrick > > > On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee < > rmukherjee@128technology.com> wrote: > > Hi Team, > > We recently published draft-abilash-quic-network-00 which proposes a > change to the QUIC protocol header that will allow network elements to > prioritize streams in QUIC packets, divert high priority streams to low > loss paths, and adjust packet pacing on a per stream basis. We have alrea= dy > received some very positive comments from some members but wanted to > solicit feedback from the larger community. Please provide your > comments/feedback/recommendations as necessary: > > > > URL: https://www.ietf.org/internet-drafts/ > draft-abilash-quic-network-00.txt > > Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 > > Thank you in advance! > > Ritesh > > > > > > --001a1145bf90de693205455ec821 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey All,

My high lev= el comment is that (from the abstract of the transport ID) "QUIC encry= pts most of its headers, thereby limiting protocol evolution=20 to QUIC endpoints only. Therefore, middleboxes, in large part, are not=20 required to be updated as new protocol versions are deployed".
unencrypting data in order to have middleboxes be updated for new protocol= versions (and their options!) is really an anti-goal of this work. This is= for both protocol evolution and application confidentiality.

= This is a strong end to end design decision - if you think the value of a t= ransport protocol instead comes from network signaling you're going to = disagree with a number of design decisions. The open questions are often ab= out how _more_ confidentiality and integrity can be created (i.e. is it fea= sible to make the connection identifier less trackable, and how a public re= set can be made less public (or if its even needed at all)) - the public st= ream id proposal blows against that headwind.

Others have made= interesting comments about the relationship between frames and packets and= there are at least 2 github issues open on priority and retransmission - C= hristian also makes a good comment in this thread about congestion control = and its embedded assumptions. Making these elements opaque to the network l= ets the transport protocol come to a consistent internal resolution to thes= e questions without depending on path behavior which is aligned with the go= al in my first paragraph.

hth explain my thoughts. Again, than= ks for taking the time to write it down. I know that can feel thankless, bu= t it really helps everyone understand crisply what is being discussed and I= sincerely appreciate it.

-Patrick

On Thu, Jan 5, 2017 at 1:20 PM, Abilash Menon <amenon@128technol= ogy.com> wrote:
Patrick,

More replies inline &= lt;amenon>

On Jan 5, 2017, at 11:50 AM, Ritesh Mukherjee <rmukherjee@128technology.com= > wrote:

Hi Patrick,
=C2=A0=
Please see inline=E2=80=A6..
=C2=A0
Ritesh
=C2=A0
= From:=C2=A0Patrick McManus [mailto:pmcmanus@mozilla.c= om]=C2=A0
Sent:=C2=A0Thursday, January 5, 2017 11:03 AM
To:=C2=A0Ritesh Muk= herjee <rmukherjee@128technology= .com>
Cc:=C2=A0IETF QUIC WG <quic@ietf= .org>
Subject:=C2=A0Re: soliciting feedback on draft-abilash-quic-= network
=C2=A0
Ritesh - thanks for taki= ng the time to write your thoughts down and sharing them.


The draft calls for r= emoving encryption of the stream ID and also adding a priority system at th= e transport level that's less expressive than the h2 one quic has to ca= rry - (also unencrypted).

[Ritesh] The stream ID and priority are authenticated= . Yes =E2=80=93 they need to be unencrypted for the network elements to opt= imize performance.

The quic charter calls for " a UDP-based, stream-multiplexi= ng, encrypted transport protocol". and "provide confidentiality [= ..] of both application data and QUIC header.".

[Ritesh] The entire statem= ent says =E2=80=9Cdescribe how those keys are used to provide confidentiali= ty and integrity protection of both application data and QUIC headers.=E2= =80=9D. The charter does not mandate not exposing any element of the QUIC h= eader even if it would improve performance.


<amenon> We would li= ke to understand your concerns as to why this would be a problem.. The draf= t calls for exposing some fields in the header so that QUIC can benefit fro= m the network. These could be made optional for clients which do not want t= o avail any network performance enhancements.

<= u>

Further, draft-= abilash's security considerations are effectively empty, which makes me= doubt things like traffic analysis, etc have been considered


<= /div>
=


[Ritesh] Ag= reed. It is work in progress. We have done testing and analysis. We will up= date it in the next iteration and suggestions are always welcome.=C2=A0=C2=A0


<am= enon> Yes. We will update the draft with more details. Please let us kno= w if there are some specific cases you would like us to address.


This doesn't sound like the m= entioned draft should be used for changes in the protocol, though it may pr= ovide useful input to the applicability and manageability statement.

<amenon> Please let us = know your concerns and we can work through them. We strongly feel this will= be useful to prioritize QUIC traffic more effectively in the network eleme= nts. This would be a way to bring application layer information into the ne= twork layer for more intelligent traffic engineering and prioritization.

Thanks,
Abilash

=

[Ritesh] We are open to = all suggestions. Our current thinking is that this should be an option in f= uture implementations.=C2=A0=C2=A0

-Patrick

= =C2=A0
=C2=A0
On Thu, Jan 5, 2017 at 10:3= 4 AM, Ritesh Mukherjee <rmukherj= ee@128technology.com> wrote:
Hi Team,
=C2=A0
We recently published draft-abilash-quic-network-00 which= proposes a change to the QUIC protocol header that will allow network elem= ents to prioritize streams in QUIC packets, divert high priority streams to= low loss paths, and adjust packet pacing on a per stream basis. We have al= ready received some very positive comments from some members but wanted to = solicit feedback from the larger community. Please provide your comments/fe= edback/recommendations as necessary:=C2=A0

=C2=A0

URL:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/= internet-drafts/draft-abilash-quic-network-00.txt

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.= ietf.org/html/draft-abilash-quic-network-00

= =C2=A0
Thank you in advance!<= /u>
=C2=A0
Ritesh
=C2=A0<= u>
=C2=A0
=

--001a1145bf90de693205455ec821-- From nobody Thu Jan 5 14:37: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 0F2151296B4 for ; Thu, 5 Jan 2017 14:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 7NmCla1TfCM9 for ; Thu, 5 Jan 2017 14:37:28 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E41A12966A for ; Thu, 5 Jan 2017 14:37:28 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id c47so532623212qtc.2 for ; Thu, 05 Jan 2017 14:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A25fNemCBWWe71GeuscmIuWYx818V/XvkVYE6GNZxf8=; b=HD5d7VdaeVUM4K8lDicJ67UgGOxN0pIJuh5dboUDfXHfjvCMCl5exDYYN/pTnuv59F CnbVxiShyAaOL4ogpY7b9GsNPzWltXHp8ST+Z7KrxxFe/pNiy9Th7vBvL0o6HIyQZ8dE tTKDTPI/KcwzpalpTaLOqiqIxD0h6TQtUBjJx13finyR/P79ZBq6Hfu1i6UY/prMuxXL Be/Q8gRZBSnbsrkwSf2+0J3ubI2hVcav/iAuk9FK3COXBrrfBgBpb8PeMmymYi0FfNh9 DeUhIXQBfIRyVEUJfLCoP13L7RC6XlArpaeeQ+o5ol6Gd+osM5IHXKfIgaRcfPBU2F9Y ZZbA== 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=A25fNemCBWWe71GeuscmIuWYx818V/XvkVYE6GNZxf8=; b=nSjMb3Fj5iunCnpK39UEN1Pg5lEDoIWA0yqlfb3wA3W/hEnV18W9nXg1ftOtUvls8X /gMbwROkYwCMD97YHvA/tXgPI6g0B/p+jOyZc5e6OPvV/DOF/zGtSz4zqa7VXF1htGQV c7I8udtDqaf+c/7PBCu3MZZ9QMVMJXRKT8oTR+nxLl+ph94vv/JU8CLMwaxOx7bsWx/f WOMrGiMvVPtJT6M35KbpTcwGS6otKdnc6COqTr3sJkia58sXXGrxMMVbR/pdU/2ZTwl2 TCWOrBrjfT0hWjKWXd4itsk9GMjc7CwTSpuUlOs+tj7kTo6a6lpnOf2wbcSRn75sIDdF 5c9g== X-Gm-Message-State: AIkVDXKrrCPhZozTReyHExD2hzUCtmnshJoOQM11mH930Xp+wyEf1zh1nKJqUFIzt2bmr0vZ X-Received: by 10.237.35.140 with SMTP id j12mr68991307qtc.5.1483655847478; Thu, 05 Jan 2017 14:37:27 -0800 (PST) Received: from abilashs-mbp-2.home (pool-173-48-109-91.bstnma.fios.verizon.net. [173.48.109.91]) by smtp.gmail.com with ESMTPSA id q3sm49171555qtc.34.2017.01.05.14.37.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Jan 2017 14:37:27 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: <021b01d2678b$a2b39980$e81acc80$@huitema.net> Date: Thu, 5 Jan 2017 17:37:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <021b01d2678b$a2b39980$e81acc80$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:37:30 -0000 Christian, Thanks for reviewing the draft. Please see replies below : > On Jan 5, 2017, at 2:40 PM, Christian Huitema = wrote: >=20 > On Thursday, January 5, 2017 7:35 AM, Ritesh Mukherjee wrote: >=20 >> We recently published draft-abilash-quic-network-00 which proposes a > change=20 >> to the QUIC protocol header that will allow network elements to = prioritize > streams >> in QUIC packets, divert high priority streams to low loss paths, and > adjust packet=20 >> pacing on a per stream basis. We have already received some very = positive > comments >> from some members but wanted to solicit feedback from the larger > community. Please >> provide your comments/feedback/recommendations as necessary:=20 >>=20 >> URL: =20 > https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt >> Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 >=20 > I have read your draft, and do not believe it should be adopted by the > working group at this point. First, we should be extremely cautious = about > adding any information in the public header, because of well = documented > issues such as middlebox interference or ossification. In particular, = there > is a long history of middle boxes doing strange things with anything = that > pretends to be a priority field. Also, the connection control pretty = much > assumes a single flow of packets forwarded with equal priorities. You = just > cannot assume the interaction between priorities and error connection = would > be beneficial.=20 We were approaching QUIC from a different perspective, where if the = network could assist QUIC protocol and also provide feedback, it would = enable the client to make more intelligent decisions. The QUIC = connection currently assumes a single connection, but our proposal would = provide an option to prioritize the streams within QUIC. For eg: lets = say the web page needs to display real content and advertisement on the = side. The content could be given a higher priority and the advertisement = could be given a lower priority. In the network, especially in = SD-WAN(Software-Defined Wide Area Network) multiple paths would be = available - a path with higher quality and one with lower quality. The = priority helps to multiplex the streams between these 2 paths. The stream ids would let the edge boxes break one QUIC session into = multiple sub sessions. A per stream state machine can be added on the = edge boxes which can provide security and enables the client to run a = per stream congestion algorithm instead of one for the whole connection.=20= >=20 > The quoted motivation for your draft is a research paper published = last May, > "How quick is QUIC" > = (https://www.researchgate.net/publication/302585207_How_quick_is_QUIC). = The > simulations reported in this paper show QUIC being generally more = efficient > than HTTP or SPDY, except in one set of conditions: high bandwidth, = large > proportion of large objects, and very low packet loss rate. It is = unclear > whether that conclusion depends on the QUIC protocol, or on = implementation > parameters used in the simulation. The authors attribute it to "the = packet > pacing mechanism in QUIC", which would be too conservative and would = unduly > slow down the transmissions.=20 >=20 > Your draft quotes that same study as [MEG2016], but comes with its own > explanation of the issue, "This is because QUIC is an end to end = protocol > and provides no means for the intermediate network elements to = contribute to > QUIC improvements." There is no mention of such explanation in = [MEG2016], > which leads me to believe that your statement is just a personal = opinion, > not based on any published study.=20 If you take the packet pacing for instance, if packets are dropped for = the connection with N streams, the packet pacing could increase the = latency. But for a case where the network could multiplex a QUIC packet = into multiple streams, the packet pacing can be done a per stream basis = that way not affecting packets on other streams. >=20 > In short, I believe that the technical solution that you propose is = not > justified by any study. Our proposal is based on the data we have gleaned from different network = conditions and deployment of existing protocols, but not from running = QUIC protocol with this proposed change itself. Please let us know if = there are some specific results you would like to see and we could run = some experiments and provide them.=20 > It would add complexity in the protocol without any > proven benefit. It would risk serious interoperability issues, and = would > greatly increase the risk of middle box interference. I don't see why = the WG > would work on that. Thanks again for your feedback. We understand that this calls for a = change in the protocol header. But this would allow the network and the = application to make smarter decisions. We can run some experiments and = get you some results. Thanks, Abilash >=20 > -- Christian Huitema >=20 >=20 >=20 From nobody Thu Jan 5 15:38:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B3A12959C for ; Thu, 5 Jan 2017 15:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 U3TCyQ-sRB61 for ; Thu, 5 Jan 2017 15:38:05 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C3F12953E for ; Thu, 5 Jan 2017 15:38:05 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s140so36577587qke.0 for ; Thu, 05 Jan 2017 15:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Px0ipfXUPh5/+y9iuK9VJf/EJvufJy1yKuiO9cgSsSY=; b=RevEoUMXEXLPXAQdUzjKZ55CBSjNS6cqONNVPksbMmz7oAGhsMRkUtng6tXScxSoUu X9IXiCx//NQE6pwOHm+8yUFZTGEmv4tlzHLyf9R29MWr2AnP1r2gMQUcIEuOMPl5hamQ vkf67rZjHIhQY3FNrh6MTukCHuBIVetmRaVjmt0MJ7kZQBupjxWLrYUXmaVIkHlHZc9A tk0EvDH4vZzXamh/QhL5vtjsLrz4G67EmsEm1+84/FJA+FdcDAxxc9JoS4ZthKZDZrpj d9+Ql4xpStqik4pSW96z0LncLitHp439J21HuLfeXb10zl6dZzotcZVxblmMSWwHkp2h UFvg== 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 :message-id:references:to; bh=Px0ipfXUPh5/+y9iuK9VJf/EJvufJy1yKuiO9cgSsSY=; b=lfuB2O2FKHDuZXJEaRDpPxe1IZ8r2li9K9rRRy/M1ikMMKGSioMYQJWcj9oACX2C5j fTCp02SzX+YadzXP8ibXoi1+h4B9vDCWTMFOhdTgVCYgSKZNiwiUxa/7oLto7F/DBtZg 4W/8NG8yFZoU2uG2E92rJdloUm//CDtAHcl/jHtx7E2+Y0ENS4AT1Uuwgzs/pQF+JIN0 TLF3O0JWE1ixQE1bS6ytDYPf17erBhIMJnWFkLAibm+BfAPkIcexfmubYblUrl/Jn9sL 38XDY1+6uIgdTfhjadjMq6evfdhVNe5CWBOPCJaMdgDAZKYkF9AmN6S6Vz5QF5QhH3ez wzHw== X-Gm-Message-State: AIkVDXIk7JrZ5BeZUxh2W2xydphL0hkCABc5W/LzBTnj73LoIzk0I9RXmM/fsChVMhbfqdXY X-Received: by 10.55.118.3 with SMTP id r3mr68082445qkc.84.1483659484325; Thu, 05 Jan 2017 15:38:04 -0800 (PST) Received: from abilashs-mbp-2.home (pool-173-48-109-91.bstnma.fios.verizon.net. [173.48.109.91]) by smtp.gmail.com with ESMTPSA id o44sm33831428qtc.8.2017.01.05.15.38.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Jan 2017 15:38:03 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D5D1BA62-F3CF-4390-B3A0-79BFD1F7F753" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: Date: Thu, 5 Jan 2017 18:38:03 -0500 Message-Id: <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 23:38:07 -0000 --Apple-Mail=_D5D1BA62-F3CF-4390-B3A0-79BFD1F7F753 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey Ted, Thanks for your feedback. Please see replies inline : > On Jan 5, 2017, at 2:57 PM, Ted Hardie wrote: >=20 > Howdy, >=20 > Forgive the top posting, but this seems to be a bit of meta-question. = If I read your draft correctly, you are suggesting that QUIC expose = stream identifiers and associate them with a priority, so that on-path = devices may move certain streams onto higher priority paths or otherwise = give variable quality of service. That is one use case yes. The on-path devices can provide quality of = services on a per stream basis.=20 >=20 > For this to work correctly, though, the basic aim of multiplexing = seems to be changed as you could not multiplex streams into the same = packet, even if they have the same desired network treatment. At that = level of isolation, independent QUIC connections may suit your use cases = just as well (if, indeed, you would choose QUIC at all). If that is the = required level of independence, why does opening different connections = not work as well? Using stream1, the connection gets established and the headers get = exchanged using stream 3. Opening multiple connections would incur more = latency for the connection setup. So with one QUIC connection, multiple = streams can leverage the same connection without taking the hit of the = connection establishment latency for each stream. >=20 > It's also not clear why you need that level of independence. At the = very least, your description makes it seem that you could multiplex = streams whose desired network treatment is the same. And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a packet). Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection.=20 > Instead, you would only need to expose the desired network treatment = for a specific packet. Why is that not enough to meet the need and why, = if that is the case, would differentiated DSCP markings not meet your = needs? Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection. Also, the stream priority = would be used to send among multiple paths in multi path case.=20 >=20 > On the latter case, there was good bit of discussion on how well = multiple DSCP markings on a single 5-tuple would work in the context of = WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=20 DSCP may not always guarantee the quality of service as it could be = remarked by the routers in between. It also depends on other factors = within the router eg: burst, packet rate etc . So the application = priority can get lost. Based on the QUIC stream priority, network = elements could remark the DSCP value to take a better path. We are not = proposing any remarking of the QUIC stream priority, but that it will = remain the same. We can add authentication to make sure the fields are = in tact. Also in DSCP case a single flow will usually be given the same = priority. In this case, the single flow/session can be given different = priorities on a per stream basis. Thanks, Abilash > Though pointing primarily at RTP flows multiplexed using BUNDLE, I = suspect many of the lessons learned would apply to your efforts, whether = you used DSCP or a different marking. >=20 > regards, >=20 > Ted >=20 >=20 >=20 > On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee = > = wrote: > Hi Team, >=20 > =20 >=20 > We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary: >=20 > =20 >=20 > URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt = > Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 = > =20 >=20 > Thank you in advance! >=20 > =20 >=20 > Ritesh >=20 > =20 >=20 >=20 --Apple-Mail=_D5D1BA62-F3CF-4390-B3A0-79BFD1F7F753 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hey Ted,

Thanks for your feedback. Please see replies inline = :

On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Howdy,

Forgive the top = posting, but this seems to be a bit of meta-question.  If I read = your draft correctly, you are suggesting that QUIC expose stream = identifiers and associate them with a priority, so that on-path devices = may move certain streams onto higher priority paths or otherwise give = variable quality of service.

That is one use case yes. The on-path devices can = provide quality of services on a per stream basis. 


For this to work correctly, though, the basic aim of = multiplexing seems to be changed as you could not multiplex streams into = the same packet, even if they have the same desired network = treatment.  At that level of isolation, independent QUIC = connections may suit your use cases just as well (if, indeed, you would = choose QUIC at all).  If that is the required level of = independence, why does opening different connections not work as = well?

Using stream1, the connection gets established and = the headers get exchanged using stream 3. Opening multiple connections = would incur more latency for the connection setup. So with one QUIC = connection, multiple streams can leverage the same connection without = taking the hit of the connection establishment latency for each = stream.


It's= also not clear why you need that level of independence. At the very = least, your description makes it seem that you could multiplex streams = whose desired network treatment is the same.  And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a = packet).

Stream = id being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing = mechanism will also benefit from this as it can be done a per stream = basis and not for the whole connection. 

  Instead, you would only = need to expose the desired network treatment for a specific = packet.  Why is that not enough to meet the need and why, if that = is the case, would differentiated DSCP markings not meet your needs?

Yes. Network treatment of a packet (priority) is = definitely needed. Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the = draft. The packet pacing mechanism will also benefit from this as it can = be done a per stream basis and not for the whole connection. Also, the = stream priority would be used to send among multiple paths in multi path = case. 


On the latter case, there was good bit = of discussion on how well multiple DSCP markings on a single 5-tuple = would work in the context of WEBRTC; if you have not read RFC 7657, I = would suggest doing so, along with draft-ietf-tsvwg-rtcweb-qos.  =

DSCP may = not always guarantee the quality of service as it could be remarked by = the routers in between. It also depends on other factors within the = router eg: burst,  packet rate etc . So the application priority = can get lost.  Based on the QUIC stream priority, network elements = could remark the DSCP value to take a better path. We are not proposing = any remarking of the QUIC stream priority, but that it will remain the = same. We can add authentication to make sure the fields are in tact. = Also in DSCP case a single flow will usually be given the same priority. = In this case, the single flow/session can be given different priorities = on a per stream basis.

Thanks,
Abilash


Though pointing primarily at RTP flows multiplexed using = BUNDLE, I suspect many of the lessons learned would apply to your = efforts, whether you used DSCP or a different = marking.
regards,

Ted



On Thu, Jan 5, 2017 at 7:34 AM, = Ritesh Mukherjee <rmukherjee@128technology.com> wrote:
<= p class=3D"MsoNormal">Hi Team,

 

We recently published = draft-abilash-quic-network-00 which proposes a change to the QUIC = protocol header that will allow network elements to prioritize streams = in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received = some very positive comments from some members but wanted to solicit = feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary:

<= u class=3D""> 

U= RL:            https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

H= tmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in advance!

 

Ritesh

 


= --Apple-Mail=_D5D1BA62-F3CF-4390-B3A0-79BFD1F7F753-- From nobody Thu Jan 5 16:08:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76349129430 for ; Thu, 5 Jan 2017 16:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 Ix1zdR9oXLZ5 for ; Thu, 5 Jan 2017 16:08:03 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74601293D6 for ; Thu, 5 Jan 2017 16:08:02 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id n21so450028533qka.3 for ; Thu, 05 Jan 2017 16:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9rJr8h8KomVA7QGqHCAb4IQD0Fd3n6Oz5mLkFqQHah8=; b=W8WScW16vF/uii16IYw9CbUk/qQkd+aH3WjK43Gi2Rv68h2xDKl4R1tLt4iOgxVYYh OZP/mSgyrAT97qwtv/qyEarTXQYHYZfhh3vHlxzk7FiNb+bKytfJ1S9MQIMhoU3W7/fW xs95d/6+65YSBHLDozWw0zr7ItvlMHMlz6E+23+RvIjLVUpMMMebvBbQjRAcDcKS/OrH +UMvJgqqkTkRQ+4xPsVwu1cVn5BXq/JBkIDZ6wyvs/IBT0X/Ix4W8oeYerzVDM5sNZfM 19RPgUxfFrEZVDt+4B9zay5sMTDyUZ9BbOXdEshBV6EHqKqJa6YI3aYjZ9HpF6m5ogAr ivlg== 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 :message-id:references:to; bh=9rJr8h8KomVA7QGqHCAb4IQD0Fd3n6Oz5mLkFqQHah8=; b=YjV0b/IF6PRGT+TxjVl3YLLcUwDw+6Ab4CJ/4BIyGuhZK3/jcAPtU1m4gSnyjMsYhs QJ9YMZ2geJsSmofbLzb6qF0CC0HHc9duaOirqpfaCPoBMklXt2NPU/Qt5iujZ1qKqq9j xyDNIbs0AudMTvyYvjjUtvxVBQtIlGCJ96ggisKjWiZWW7/Ie/tQS2lDcNWMeO2gxfKs W/m7SGi3THL5Y4DLktgsSsg67lezXHVYAzIl536SXKVLWMWUlqtMny6heQ2eVOYExMqH mYOY5cdoXaCWPB0qwrQ79u6aXaukEDwXOFpkcZ+vhtFXO1qop3MNmnQW1kmnNPW2Nm7o 5vew== X-Gm-Message-State: AIkVDXITV8A048E6w6W2bigCVfGnnjMcfKKxMUkDMicD0JmY+yxUZhrgbzbOAaE5xC728PNI X-Received: by 10.55.94.199 with SMTP id s190mr79094831qkb.159.1483661281743; Thu, 05 Jan 2017 16:08:01 -0800 (PST) Received: from abilashs-mbp-2.home (pool-173-48-109-91.bstnma.fios.verizon.net. [173.48.109.91]) by smtp.gmail.com with ESMTPSA id q88sm38893300qkq.21.2017.01.05.16.08.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Jan 2017 16:08:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FEEF1202-354D-4284-A4F4-3C64F471C657" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: Date: Thu, 5 Jan 2017 19:08:00 -0500 Message-Id: References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <02a401d26773$c97fedb0$5c7fc910$@128technology.com> To: Patrick McManus X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 00:08:04 -0000 --Apple-Mail=_FEEF1202-354D-4284-A4F4-3C64F471C657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Patrick, > On Jan 5, 2017, at 3:31 PM, Patrick McManus = wrote: >=20 > Hey All, >=20 > My high level comment is that (from the abstract of the transport ID) = "QUIC encrypts most of its headers, thereby limiting protocol evolution = to QUIC endpoints only. Therefore, middleboxes, in large part, are not = required to be updated as new protocol versions are deployed".=20 >=20 > unencrypting data in order to have middleboxes be updated for new = protocol versions (and their options!) is really an anti-goal of this = work. This is for both protocol evolution and application = confidentiality. Sure. We understand the sentiment. Our goal was to see how QUIC could = be provided more assistance from the network. Priority plays a big role = in classifying the streams and the stream id for providing better = feedback and state machine establishment. As for protocol evolution, as = long as its a tlv format and has backward compatibility, it should not = be an issue. This could be a separate header section just for network = elements and optional. We can add capability flags for the same. Would = this be something you would be open to - an optional header. We are viewing QUIC as something that will eventually replace TCP for a = lot of applications. We currently can parse the TCP packet and have = state machines implemented for it in our network elements. Unfortunately = there is no priority set by each packet. Also stream id, would provide = better analytics on the network on a per connection basis.=20 >=20 > This is a strong end to end design decision - if you think the value = of a transport protocol instead comes from network signaling you're = going to disagree with a number of design decisions. The open questions = are often about how _more_ confidentiality and integrity can be created = (i.e. is it feasible to make the connection identifier less trackable, = and how a public reset can be made less public (or if its even needed at = all)) - the public stream id proposal blows against that headwind. Interesting. The session could still be identified using the 5 tuple = for sure. But looks like the approach is to hide everything possible = for security reasons. Are there no thoughts on getting network = assistance where possible ? What about priority per packet. Is that a = cause for concern as well. The protocol can get feedback as well as = assistance from the network. >=20 > Others have made interesting comments about the relationship between = frames and packets and there are at least 2 github issues open on = priority and retransmission - Christian also makes a good comment in = this thread about congestion control and its embedded assumptions. = Making these elements opaque to the network lets the transport protocol = come to a consistent internal resolution to these questions without = depending on path behavior which is aligned with the goal in my first = paragraph. >=20 > hth explain my thoughts. Again, thanks for taking the time to write it = down. I know that can feel thankless, but it really helps everyone = understand crisply what is being discussed and I sincerely appreciate = it. Thank you again for taking the time to go through your different = concerns. We would like to follow up on this and see if the group is = open to an optional network header element and priority. This way only = clients can choose to avail this assistance if needed. This would be a = good use-case in SD-WAN scenarios. Thanks, Abilash >=20 > -Patrick >=20 >=20 > On Thu, Jan 5, 2017 at 1:20 PM, Abilash Menon = > wrote: > Patrick, >=20 > More replies inline >=20 >> On Jan 5, 2017, at 11:50 AM, Ritesh Mukherjee = > = wrote: >>=20 >> Hi Patrick, >> =20 >> Please see inline=E2=80=A6.. >> =20 >> Ritesh >> =20 >> =C2=A0 <> >> From: Patrick McManus [mailto:pmcmanus@mozilla.com = ]=20 >> Sent: Thursday, January 5, 2017 11:03 AM >> To: Ritesh Mukherjee > >> Cc: IETF QUIC WG > >> Subject: Re: soliciting feedback on draft-abilash-quic-network >> =20 >> Ritesh - thanks for taking the time to write your thoughts down and = sharing them. >>=20 >> The draft calls for removing encryption of the stream ID and also = adding a priority system at the transport level that's less expressive = than the h2 one quic has to carry - (also unencrypted). >>=20 >> [Ritesh] The stream ID and priority are authenticated. Yes =E2=80=93 = they need to be unencrypted for the network elements to optimize = performance. >>=20 >> The quic charter calls for " a UDP-based, stream-multiplexing, = encrypted transport protocol". and "provide confidentiality [..] of both = application data and QUIC header.". >>=20 >> [Ritesh] The entire statement says =E2=80=9Cdescribe how those keys = are used to provide confidentiality and integrity protection of both = application data and QUIC headers.=E2=80=9D. The charter does not = mandate not exposing any element of the QUIC header even if it would = improve performance. >>=20 >=20 > We would like to understand your concerns as to why this = would be a problem.. The draft calls for exposing some fields in the = header so that QUIC can benefit from the network. These could be made = optional for clients which do not want to avail any network performance = enhancements. >=20 >> Further, draft-abilash's security considerations are effectively = empty, which makes me doubt things like traffic analysis, etc have been = considered >>=20 >>=20 >>=20 >> [Ritesh] Agreed. It is work in progress. We have done testing and = analysis. We will update it in the next iteration and suggestions are = always welcome. =20 >>=20 >=20 > Yes. We will update the draft with more details. Please let = us know if there are some specific cases you would like us to address. >=20 >>=20 >> This doesn't sound like the mentioned draft should be used for = changes in the protocol, though it may provide useful input to the = applicability and manageability statement. >>=20 >=20 > Please let us know your concerns and we can work through = them. We strongly feel this will be useful to prioritize QUIC traffic = more effectively in the network elements. This would be a way to bring = application layer information into the network layer for more = intelligent traffic engineering and prioritization. >=20 > Thanks, > Abilash >=20 >> [Ritesh] We are open to all suggestions. Our current thinking is that = this should be an option in future implementations. =20 >>=20 >> -Patrick >>=20 >> =20 >> =20 >> On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee = > = wrote: >>> Hi Team, >>> =20 >>> We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary:=20 >>> =20 >>>=20 >>> URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt = >>> Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 = >>> =20 >>> Thank you in advance! >>> =20 >>> Ritesh >>> =20 >>=20 >> =20 >=20 >=20 --Apple-Mail=_FEEF1202-354D-4284-A4F4-3C64F471C657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Patrick,

<amenon> Please let us know your concerns and we can = work through them. We strongly feel this will be useful to prioritize = QUIC traffic more effectively in the network elements. This would be a = way to bring application layer information into the network layer for = more intelligent traffic engineering and prioritization.

Thanks,
Abilash

[Ritesh] We are open to all = suggestions. Our current thinking is that this should be an option in = future implementations.  

-Patrick

 
 
On Thu, Jan 5, 2017 at 10:34 AM, Ritesh = Mukherjee <rmukherjee@128technology.com> wrote:
Hi = Team,
 
We recently published draft-abilash-quic-network-00 which = proposes a change to the QUIC protocol header that will allow network = elements to prioritize streams in QUIC packets, divert high priority = streams to low loss paths, and adjust packet pacing on a per stream = basis. We have already received some very positive comments from some = members but wanted to solicit feedback from the larger community. Please = provide your comments/feedback/recommendations as = necessary: =

 

URL:         &n= bsp;  https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

 
Thank you in advance!
 
Ritesh
 
 



= --Apple-Mail=_FEEF1202-354D-4284-A4F4-3C64F471C657-- From nobody Thu Jan 5 16:09: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 DB80112943D for ; Thu, 5 Jan 2017 16:09: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, 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 XkgCOcredcpx for ; Thu, 5 Jan 2017 16:09:15 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE00C1293D6 for ; Thu, 5 Jan 2017 16:09:14 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s140so37187651qke.0 for ; Thu, 05 Jan 2017 16:09: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=0ZM2cOP0AJqxUaijZB2lQtQtCfCS9yHGLZ9LBTy+asc=; b=H7llyiD50kaJT+Ej5HTKgcbunLI5J9CsTXc3pSsQvCy2ez191VqNrIJajgx8k1DFun v0vOJpEHWZKB5IxVWTux337GUZPuQoEoVXVS7FHNv3KYSQIbyzdmLAJFXMQJGrdUjJrV vsrQJFjznPclC8lL05lB6Ue/8E5e8j3LatHQqTnTTRygGvB5RfQTclMDEGIwVJ6lh70e iGStskfBq/nveSIAQwzpIwE8vL2pi+F3a9x2K4UYh3f/rGE12BFdAETykX2fBpsHSkpy ccxYaItDZyXE5MTPmNCDZ9cgF79XFhXD4QtNkR6A357OKCXDv4ylRKJIBlZqKnP2ec35 A2WQ== 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=0ZM2cOP0AJqxUaijZB2lQtQtCfCS9yHGLZ9LBTy+asc=; b=Zoo61zsFzYRJeIJ+2hm8SrfXmoeYdUyb+BkNCt04xcLbMWsHIHwJ6BEW9n9yujIak+ L2p4g8PQJB5jmoE4veVyazAIsvGC9ewQSGEwc0tkvoKxuFyjxfbkw6PZpgR0a6I+QR0B kDoIMpGyVIfTQGvYlQj+fWCmb/RvgpCEi1dQbauWjkuBxKbSQqAASVRgTcEdiWnn/8bR wQC0OWWn21e2evXjqxx+9mCsyNykSBcGfCpOiMGOcH1IElYaqyN/XSQV+rS4lPm7C9X2 y8O6XlFBTgqj0bwGtabBssYuU0PGPpkodqzwA5czYfYT6O3jrdWxlujYGolF1UwP4tJL kdYw== X-Gm-Message-State: AIkVDXJCUV489cCAhOFNK/Q9Xdgh4s9Cq5prhWFFxDKetzZ0mbeLKySbUAbxt0XLD23bFYjTL9B2qxV1GPUTJg== X-Received: by 10.55.71.74 with SMTP id u71mr81144619qka.251.1483661353980; Thu, 05 Jan 2017 16:09:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.182.66 with HTTP; Thu, 5 Jan 2017 16:08:43 -0800 (PST) In-Reply-To: <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> From: Ted Hardie Date: Thu, 5 Jan 2017 16:08:43 -0800 Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Abilash Menon Content-Type: multipart/alternative; boundary=001a114a7edef8972e054561d3c7 Archived-At: Cc: Ritesh Mukherjee , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 00:09:17 -0000 --001a114a7edef8972e054561d3c7 Content-Type: text/plain; charset=UTF-8 Reply in-line. On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon wrote: > Hey Ted, > > Thanks for your feedback. Please see replies inline : > > On Jan 5, 2017, at 2:57 PM, Ted Hardie wrote: > > Howdy, > > Forgive the top posting, but this seems to be a bit of meta-question. If > I read your draft correctly, you are suggesting that QUIC expose stream > identifiers and associate them with a priority, so that on-path devices may > move certain streams onto higher priority paths or otherwise give variable > quality of service. > > > That is one use case yes. The on-path devices can provide quality of > services on a per stream basis. > > > For this to work correctly, though, the basic aim of multiplexing seems to > be changed as you could not multiplex streams into the same packet, even if > they have the same desired network treatment. At that level of isolation, > independent QUIC connections may suit your use cases just as well (if, > indeed, you would choose QUIC at all). If that is the required level of > independence, why does opening different connections not work as well? > > > Using stream1, the connection gets established and the headers get > exchanged using stream 3. Opening multiple connections would incur more > latency for the connection setup. So with one QUIC connection, multiple > streams can leverage the same connection without taking the hit of the > connection establishment latency for each stream. > With 0RTT, this is probably not an issue for a long-lived flows, and it has to be compared to the cost for application mechanics to make sure that each packet contains elements from only a single stream. For a multiplexing protocol, the latter seems fundamentally sub-optimal. > > > It's also not clear why you need that level of independence. At the very > least, your description makes it seem that you could multiplex streams > whose desired network treatment is the same. And, if you did multiplex > streams with the same desired network treatment, there seems to be no need > at all to expose the stream identifiers (after all, you might have more > than one stream in a packet). > > > Stream id being exposed would help build QUIC state machine in the network > elements for each stream as mentioned in the draft. The packet pacing > mechanism will also benefit from this as it can be done a per stream basis > and not for the whole connection. > > So, "building the QUIC state machine in the network elements" doesn't mean much absent a knowledge of what those network elements are going to do with the state. The use case that you mentioned originally, path selection for network treatment, doesn't actually require that the on-path elements distinguish among streams that require like treatment. It simply requires that the requested network treatment be visible. Given that multiplexing streams that require like network treatment works with the multiplexed design of QUIC, I'm still unclear why you want to insist on such a strict independence. Instead, you would only need to expose the desired network treatment for > a specific packet. Why is that not enough to meet the need and why, if > that is the case, would differentiated DSCP markings not meet your needs? > > > Yes. Network treatment of a packet (priority) is definitely needed. Stream > id being exposed would help build QUIC state machine in the network > elements for each stream as mentioned in the draft. The packet pacing > mechanism will also benefit from this as it can be done a per stream basis > and not for the whole connection. > Your draft says this: However, session aware routers will have a flow per stream. Hence the packet rate can be adjusted on a per stream basis and not for the whole connection. Once again, this seems to run counter to the design of a multiplexed protocol, and the description in the document is a bit circular. A session aware router certainly would not have a flow per stream as QUIC is designed now; it would have no way to create such a flow. You are motivating the change in QUIC in order to achieve that for session aware routers, but without addressing the loss of other basic QUIC design features. > Also, the stream priority would be used to send among multiple paths in > multi path case. > > > > On the latter case, there was good bit of discussion on how well multiple > DSCP markings on a single 5-tuple would work in the context of WEBRTC; if > you have not read RFC 7657, I would suggest doing so, along with > draft-ietf-tsvwg-rtcweb-qos. > > > DSCP may not always guarantee the quality of service as it could be > remarked by the routers in between. It also depends on other factors within > the router eg: burst, packet rate etc . So the application priority can > get lost. Based on the QUIC stream priority, network elements could remark > the DSCP value to take a better path. > So, I recommended you look at the document because it treats the problem of having a single five(or six)-tuple flow have different markings. Evidently, your basic answer is to replace the current flow-state management with a different view of the flow ("session"), using the stream id as a demultiplexing signal. You then wish to have a marking for the session. One of the design goals of QUIC is that it be deployable on the Internet as it exists, rather than relying on features which must be introduced into the network to support it. This effort seems to run counter to that design goal as well. > We are not proposing any remarking of the QUIC stream priority, but that > it will remain the same. We can add authentication to make sure the fields > are in tact. Also in DSCP case a single flow will usually be given the same > priority. In this case, the single flow/session can be given different > priorities on a per stream basis. > > Of course, there is a potential silly state here if the session-state aware network elements do something on one signal and their non-session-state peers act on a different signal; at best, you'd have to scrub and re-mark to avoid that. Given that, I fail to see why the multiple-markings within a flow approach of RFC 7657 doesn't work at least as well, at least for the Internet as currently deployed. regards, Ted > Thanks, > Abilash > > > Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect > many of the lessons learned would apply to your efforts, whether you used > DSCP or a different marking. > > > regards, > > Ted > > > > On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < > rmukherjee@128technology.com> wrote: > >> Hi Team, >> >> >> >> We recently published draft-abilash-quic-network-00 which proposes a >> change to the QUIC protocol header that will allow network elements to >> prioritize streams in QUIC packets, divert high priority streams to low >> loss paths, and adjust packet pacing on a per stream basis. We have already >> received some very positive comments from some members but wanted to >> solicit feedback from the larger community. Please provide your >> comments/feedback/recommendations as necessary: >> >> >> >> URL: https://www.ietf.org/internet- >> drafts/draft-abilash-quic-network-00.txt >> >> Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 >> >> >> >> Thank you in advance! >> >> >> >> Ritesh >> >> >> > > > --001a114a7edef8972e054561d3c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reply in-line.

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <= amenon@128technology.com> wrote:
Hey Ted,=

Thanks for your feedback. Please see replies inline :

On = Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

=
Howdy,

Forgive the top posting, but this seems = to be a bit of meta-question.=C2=A0 If I read your draft correctly, you are= suggesting that QUIC expose stream identifiers and associate them with a p= riority, so that on-path devices may move certain streams onto higher prior= ity paths or otherwise give variable quality of service.

That is one use case yes. = The on-path devices can provide quality of services on a per stream basis.= =C2=A0


For this to work correctly, though, the bas= ic aim of multiplexing seems to be changed as you could not multiplex strea= ms into the same packet, even if they have the same desired network treatme= nt.=C2=A0 At that level of isolation, independent QUIC connections may suit= your use cases just as well (if, indeed, you would choose QUIC at all).=C2= =A0 If that is the required level of independence, why does opening differe= nt connections not work as well?
Using stream1, the connection gets established and the h= eaders get exchanged using stream 3. Opening multiple connections would inc= ur more latency for the connection setup. So with one QUIC connection, mult= iple streams can leverage the same connection without taking the hit of the= connection establishment latency for each stream.
<= /blockquote>

With 0RTT, this is probably not an issue fo= r a long-lived flows, and it has to be compared to the cost for application= mechanics to make sure that each packet contains elements from only a sing= le stream.=C2=A0 For a multiplexing protocol, the latter seems fundamentall= y sub-optimal.
=C2=A0

It's also not clear why you need that level of independence. At the v= ery least, your description makes it seem that you could multiplex streams = whose desired network treatment is the same.=C2=A0 And, if you did multiple= x streams with the same desired network treatment, there seems to be no nee= d at all to expose the stream identifiers (after all, you might have more t= han one stream in a packet).

<= /span>Stream id being exposed would help build QUIC state machine in the ne= twork elements for each stream as mentioned in the draft. The packet pacing= mechanism will also benefit from this as it can be done a per stream basis= and not for the whole connection.=C2=A0
<= br>

So, "buil= ding the QUIC state machine in the network elements" doesn't mean = much absent a knowledge of what those network elements are going to do with= the state.=C2=A0 The use case that you mentioned originally, path selectio= n for network treatment, doesn't actually require that the on-path elem= ents distinguish among streams that require like treatment.=C2=A0 It simply= requires that the requested network treatment be visible.=C2=A0 Given that= multiplexing streams that require like network treatment works with the mu= ltiplexed design of QUIC, I'm still unclear why you want to insist on s= uch a strict independence.

<= div>=C2=A0 Instead, you would only need to expose the desired network treat= ment for a specific packet.=C2=A0 Why is that not enough to meet the need a= nd why, if that is the case, would differentiated DSCP markings not meet yo= ur needs?

Yes.= Network treatment of a packet (priority) is definitely needed. Stream id b= eing exposed would help build QUIC state machine in the network elements fo= r each stream as mentioned in the draft. The packet pacing mechanism will a= lso benefit from this as it can be done a per stream basis and not for the = whole connection.

Y= our draft says this:

   However, sessio=
n aware routers will have a flow per
   stream.  Hence the packet rate can be adjusted on a per stream basis
   and not for the whole connection.
Once again, this seems= to run counter to the design of a multiplexed protocol, and the descriptio= n in the document is a bit circular.=C2=A0 A session aware router certainly= would not have a flow per stream as QUIC is designed now; it would have no= way to create such a flow.=C2=A0 You are motivating the change in QUIC in = order to achieve that for session aware routers, but without addressing the= loss of other basic QUIC design features.
=C2=A0
Also, the stream priority would be used to send = among multiple paths in multi path case.=C2=A0
=

=C2=A0

On the latter case, there was good bit of di= scussion on how well multiple DSCP markings on a single 5-tuple would work = in the context of WEBRTC; if you have not read RFC 7657, I would suggest do= ing so, along with draft-ietf-tsvwg-rtcweb-qos.=C2=A0

DSCP may not always guarantee the qual= ity of service as it could be remarked by the routers in between. It also d= epends on other factors within the router eg: burst, =C2=A0packet rate etc = . So the application priority can get lost.=C2=A0 Based on the QUIC stream = priority, network elements could remark the DSCP value to take a better pat= h.

So, I recommend= ed you look at the document because it treats the problem of having a singl= e five(or six)-tuple flow have different markings.=C2=A0 Evidently, your ba= sic answer is to replace the current flow-state management with a different= view of the flow ("session"), using the stream id as a demultipl= exing signal.=C2=A0 You then wish to have a marking for the session.=C2=A0 =

One of the design goals of QUIC is that it be deployable= on the Internet as it exists, rather than relying on features which must b= e introduced into the network to support it.=C2=A0 This effort seems to run= counter to that design goal as well.
=C2=A0
We are not proposing any remarking of the QUIC stream = priority, but that it will remain the same. We can add authentication to ma= ke sure the fields are in tact. Also in DSCP case a single flow will usuall= y be given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis.


Of course, there is a potential si= lly state here if the session-state aware network elements do something on = one signal and their non-session-state peers act on a different signal; at = best, you'd have to scrub and re-mark to avoid that.=C2=A0 Given that, = I fail to see why the multiple-markings within a flow approach of RFC 7657 = doesn't work at least as well, at least for the Internet as currently d= eployed.

regards,

Ted
=C2=A0<= /div>
Thanks,
Abilash


Though pointing primarily at RTP flows= multiplexed using BUNDLE, I suspect many of the lessons learned would appl= y to your efforts, whether you used DSCP or a different marking.
regards,

Ted



= On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee <rmukherjee@12= 8technology.com> wrote:

Hi = Team,

=C2=A0

We = recently published draft-abilash-quic-network-00 which proposes a change to= the QUIC protocol header that will allow network elements to prioritize st= reams in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received some v= ery positive comments from some members but wanted to solicit feedback from= the larger community. Please provide your comments/feedback/recommendations as necessary:

= =C2=A0

URL:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-0= 0.txt

Htmlized:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-abilash-quic-network-00

=C2=A0=

Thank you in advance!=

=C2=A0=

Ritesh

=C2=A0=




--001a114a7edef8972e054561d3c7-- From nobody Thu Jan 5 19:52:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EBF129874 for ; Thu, 5 Jan 2017 19:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, 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 WKVWKjJI1HCo for ; Thu, 5 Jan 2017 19:52:41 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 6125D1297BF for ; Thu, 5 Jan 2017 19:52:41 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id p9so309085236vkd.3 for ; Thu, 05 Jan 2017 19:52: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=bzjO0vHWOTnZrOeQWgAG5dxSTxJEtkSMe/ejsnH8OQs=; b=bDO2VG1LLHjvEas3YgTHUF3jHI+JTGrbXZwLms10uNNqDp8Bgm/vdN28oQzkQHy23d 9UpZ/FMAEi1bp709pkhcG8hRJTW91z3KFtiHhXRGlSptmINgFzwCQ+yjKwu2l4gmjzxr lHKTW+a8bT+q3uoCDjfGFMMKr5UqMsdLDXDuga9ZJwBv3c4eZ/s/XFWMXfJbLXZWBU+O KxJbZ3A96xoSTLk2zCr3JG1s2jpY9Yr48BPApgfq5GXh8AWQNk2p043E64MBQmjIjmlU QErWv796uOER1kl1jTiY3wiVRY9XRz8IPUaACiGpp9qUWV+oBrrY0eUz+EmSf184a8te t08g== 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=bzjO0vHWOTnZrOeQWgAG5dxSTxJEtkSMe/ejsnH8OQs=; b=KCNGiyMCRaSVxkbOyOCwZN8YS3IskVG2HdauPsMBe15zbTxoHTw7WNyhLWaEzyRUBB 2Ny4V7hFC66ZXXdAlvIlvA+AKpY6Wf/uBhO0r/QOZU0k3Uzj8slddpn5ZdmuxWEweCRD S/5QCUPNi8WoxAzP0J5DTi/2vfiy5+9lk5BtO53EBit1Ep9YWWYlklkcsw+5QQZpS66Y xawORgqyKA6I9moB7SCbBguD7QgPRcjBLSSNYfZcTNgY2Sgj3uZM3Teto93fGjWSw77x Qru9rsjrNNBVpkwUjp7pnwvQbSLEh1Q2UoIaAIzmslowPdpMpcGhD8N3toHBlqDvfTRN Uo/g== X-Gm-Message-State: AIkVDXK5ESQw0VkLUhWc30qzWCBhZ5qGLcpjnLYIAalvmuK1JHdSmyKPSFzoZ2gJ78qF3PUFTOCaXbOIdsNdbZz/ X-Received: by 10.31.52.145 with SMTP id b139mr22408577vka.151.1483674760292; Thu, 05 Jan 2017 19:52:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Thu, 5 Jan 2017 19:52:39 -0800 (PST) In-Reply-To: References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> From: Jana Iyengar Date: Thu, 5 Jan 2017 19:52:39 -0800 Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Ted Hardie Content-Type: multipart/alternative; boundary=001a114348b60d10b8054564f345 Archived-At: Cc: Abilash Menon , Ritesh Mukherjee , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 03:52:43 -0000 --001a114348b60d10b8054564f345 Content-Type: text/plain; charset=UTF-8 Hi, Thanks for writing up the draft -- as Patrick notes, it's helpful to have something concrete to discuss. I have a number of thoughts as I catch up on this thread, but I have a high-order one: have you considered proposing this draft for HTTP/2? Given that the use of streams is basically the same for HTTP/2 and HTTP over QUIC, I would expect that signaling stream IDs and priorities for HTTP/2 should be similar. Why not propose it for HTTP/2? There are a significant number of engineering issues with doing priorities per stream, the most significant one being the one that Christian points out: that congestion control and loss detection will need to be per-stream, defeating a major rationale for stream multiplexing. That is a show-stopper, in my opinion. You'd have the same troubles with TCP and HTTP/2. I don't think prioritizing streams by network elements makes good engineering sense. - jana On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie wrote: > Reply in-line. > > On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon > wrote: > >> Hey Ted, >> >> Thanks for your feedback. Please see replies inline : >> >> On Jan 5, 2017, at 2:57 PM, Ted Hardie wrote: >> >> Howdy, >> >> Forgive the top posting, but this seems to be a bit of meta-question. If >> I read your draft correctly, you are suggesting that QUIC expose stream >> identifiers and associate them with a priority, so that on-path devices may >> move certain streams onto higher priority paths or otherwise give variable >> quality of service. >> >> >> That is one use case yes. The on-path devices can provide quality of >> services on a per stream basis. >> >> >> For this to work correctly, though, the basic aim of multiplexing seems >> to be changed as you could not multiplex streams into the same packet, even >> if they have the same desired network treatment. At that level of >> isolation, independent QUIC connections may suit your use cases just as >> well (if, indeed, you would choose QUIC at all). If that is the required >> level of independence, why does opening different connections not work as >> well? >> >> >> Using stream1, the connection gets established and the headers get >> exchanged using stream 3. Opening multiple connections would incur more >> latency for the connection setup. So with one QUIC connection, multiple >> streams can leverage the same connection without taking the hit of the >> connection establishment latency for each stream. >> > > With 0RTT, this is probably not an issue for a long-lived flows, and it > has to be compared to the cost for application mechanics to make sure that > each packet contains elements from only a single stream. For a > multiplexing protocol, the latter seems fundamentally sub-optimal. > > >> >> >> It's also not clear why you need that level of independence. At the very >> least, your description makes it seem that you could multiplex streams >> whose desired network treatment is the same. And, if you did multiplex >> streams with the same desired network treatment, there seems to be no need >> at all to expose the stream identifiers (after all, you might have more >> than one stream in a packet). >> >> >> Stream id being exposed would help build QUIC state machine in the >> network elements for each stream as mentioned in the draft. The packet >> pacing mechanism will also benefit from this as it can be done a per stream >> basis and not for the whole connection. >> >> > So, "building the QUIC state machine in the network elements" doesn't mean > much absent a knowledge of what those network elements are going to do with > the state. The use case that you mentioned originally, path selection for > network treatment, doesn't actually require that the on-path elements > distinguish among streams that require like treatment. It simply requires > that the requested network treatment be visible. Given that multiplexing > streams that require like network treatment works with the multiplexed > design of QUIC, I'm still unclear why you want to insist on such a strict > independence. > > Instead, you would only need to expose the desired network treatment for >> a specific packet. Why is that not enough to meet the need and why, if >> that is the case, would differentiated DSCP markings not meet your needs? >> >> >> Yes. Network treatment of a packet (priority) is definitely needed. >> Stream id being exposed would help build QUIC state machine in the network >> elements for each stream as mentioned in the draft. The packet pacing >> mechanism will also benefit from this as it can be done a per stream basis >> and not for the whole connection. >> > > Your draft says this: > > However, session aware routers will have a flow per > stream. Hence the packet rate can be adjusted on a per stream basis > and not for the whole connection. > > Once again, this seems to run counter to the design of a multiplexed > protocol, and the description in the document is a bit circular. A session > aware router certainly would not have a flow per stream as QUIC is designed > now; it would have no way to create such a flow. You are motivating the > change in QUIC in order to achieve that for session aware routers, but > without addressing the loss of other basic QUIC design features. > > >> Also, the stream priority would be used to send among multiple paths in >> multi path case. >> >> > > >> >> On the latter case, there was good bit of discussion on how well multiple >> DSCP markings on a single 5-tuple would work in the context of WEBRTC; if >> you have not read RFC 7657, I would suggest doing so, along with >> draft-ietf-tsvwg-rtcweb-qos. >> >> >> DSCP may not always guarantee the quality of service as it could be >> remarked by the routers in between. It also depends on other factors within >> the router eg: burst, packet rate etc . So the application priority can >> get lost. Based on the QUIC stream priority, network elements could remark >> the DSCP value to take a better path. >> > > So, I recommended you look at the document because it treats the problem > of having a single five(or six)-tuple flow have different markings. > Evidently, your basic answer is to replace the current flow-state > management with a different view of the flow ("session"), using the stream > id as a demultiplexing signal. You then wish to have a marking for the > session. > > One of the design goals of QUIC is that it be deployable on the Internet > as it exists, rather than relying on features which must be introduced into > the network to support it. This effort seems to run counter to that design > goal as well. > > >> We are not proposing any remarking of the QUIC stream priority, but that >> it will remain the same. We can add authentication to make sure the fields >> are in tact. Also in DSCP case a single flow will usually be given the same >> priority. In this case, the single flow/session can be given different >> priorities on a per stream basis. >> >> > Of course, there is a potential silly state here if the session-state > aware network elements do something on one signal and their > non-session-state peers act on a different signal; at best, you'd have to > scrub and re-mark to avoid that. Given that, I fail to see why the > multiple-markings within a flow approach of RFC 7657 doesn't work at least > as well, at least for the Internet as currently deployed. > > regards, > > Ted > > >> Thanks, >> Abilash >> >> >> Though pointing primarily at RTP flows multiplexed using BUNDLE, I >> suspect many of the lessons learned would apply to your efforts, whether >> you used DSCP or a different marking. >> >> >> regards, >> >> Ted >> >> >> >> On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < >> rmukherjee@128technology.com> wrote: >> >>> Hi Team, >>> >>> >>> >>> We recently published draft-abilash-quic-network-00 which proposes a >>> change to the QUIC protocol header that will allow network elements to >>> prioritize streams in QUIC packets, divert high priority streams to low >>> loss paths, and adjust packet pacing on a per stream basis. We have already >>> received some very positive comments from some members but wanted to >>> solicit feedback from the larger community. Please provide your >>> comments/feedback/recommendations as necessary: >>> >>> >>> >>> URL: https://www.ietf.org/internet- >>> drafts/draft-abilash-quic-network-00.txt >>> >>> Htmlized: https://tools.ietf.org/html/dr >>> aft-abilash-quic-network-00 >>> >>> >>> >>> Thank you in advance! >>> >>> >>> >>> Ritesh >>> >>> >>> >> >> >> > --001a114348b60d10b8054564f345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for writing up the draft -- = as Patrick notes, it's helpful to have something concrete to discuss.

I have a number of thoughts as I catch up on this t= hread, but I have a high-order one: have you considered proposing this draf= t for HTTP/2? Given that the use of streams is basically the same for HTTP/= 2 and HTTP over QUIC, I would expect that signaling stream IDs and prioriti= es for HTTP/2 should be similar. Why not propose it for HTTP/2?
<= br>
There are a significant number of engineering issues with doi= ng priorities per stream, the most significant one being the one that Chris= tian points out: that congestion control and loss detection will need to be= per-stream, defeating a major rationale for stream multiplexing. That is a= show-stopper, in my opinion. You'd have the same troubles with TCP and= HTTP/2.

I don't think prioritizing streams by= network elements makes good engineering sense.

- = jana


On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie = <ted.ietf@gmail.= com> wrote:
Reply in-line.

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <= amenon@128technology.com> wrote:
Hey Ted,

Thanks for your f= eedback. Please see replies inline :

On Jan 5, 2017, at = 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Howdy,

Forgive the top posting, but this s= eems to be a bit of meta-question.=C2=A0 If I read your draft correctly, yo= u are suggesting that QUIC expose stream identifiers and associate them wit= h a priority, so that on-path devices may move certain streams onto higher = priority paths or otherwise give variable quality of service.

That is one use case = yes. The on-path devices can provide quality of services on a per stream ba= sis.=C2=A0


For this to work c= orrectly, though, the basic aim of multiplexing seems to be changed as you = could not multiplex streams into the same packet, even if they have the sam= e desired network treatment.=C2=A0 At that level of isolation, independent = QUIC connections may suit your use cases just as well (if, indeed, you woul= d choose QUIC at all).=C2=A0 If that is the required level of independence,= why does opening different connections not work as well?

Using stream1, the connection g= ets established and the headers get exchanged using stream 3. Opening multi= ple connections would incur more latency for the connection setup. So with = one QUIC connection, multiple streams can leverage the same connection with= out taking the hit of the connection establishment latency for each stream.=

With 0RTT, = this is probably not an issue for a long-lived flows, and it has to be comp= ared to the cost for application mechanics to make sure that each packet co= ntains elements from only a single stream.=C2=A0 For a multiplexing protoco= l, the latter seems fundamentally sub-optimal.
=C2=A0
=


It's also not clear why you need tha= t level of independence. At the very least, your description makes it seem = that you could multiplex streams whose desired network treatment is the sam= e.=C2=A0 And, if you did multiplex streams with the same desired network tr= eatment, there seems to be no need at all to expose the stream identifiers = (after all, you might have more than one stream in a packet).

Stream id being exposed would help b= uild QUIC state machine in the network elements for each stream as mentione= d in the draft. The packet pacing mechanism will also benefit from this as = it can be done a per stream basis and not for the whole connection.=C2=A0


So, "building the QUIC = state machine in the network elements" doesn't mean much absent a = knowledge of what those network elements are going to do with the state.=C2= =A0 The use case that you mentioned originally, path selection for network = treatment, doesn't actually require that the on-path elements distingui= sh among streams that require like treatment.=C2=A0 It simply requires that= the requested network treatment be visible.=C2=A0 Given that multiplexing = streams that require like network treatment works with the multiplexed desi= gn of QUIC, I'm still unclear why you want to insist on such a strict i= ndependence.

=C2=A0 In= stead, you would only need to expose the desired network treatment for a sp= ecific packet.=C2=A0 Why is that not enough to meet the need and why, if th= at is the case, would differentiated DSCP markings not meet your needs?
=

Yes. Network trea= tment of a packet (priority) is definitely needed. Stream id being exposed = would help build QUIC state machine in the network elements for each stream= as mentioned in the draft. The packet pacing mechanism will also benefit f= rom this as it can be done a per stream basis and not for the whole connect= ion.

Your dr= aft says this:

   =
However, session aware routers will have a flow per
   stream.  Hence the packet rate can be adjusted on a per stream basis
   and not for the whole connection.
Once again, this seems= to run counter to the design of a multiplexed protocol, and the descriptio= n in the document is a bit circular.=C2=A0 A session aware router certainly= would not have a flow per stream as QUIC is designed now; it would have no= way to create such a flow.=C2=A0 You are motivating the change in QUIC in = order to achieve that for session aware routers, but without addressing the= loss of other basic QUIC design features.
= =C2=A0
Also, the stream priority would be used to send among multiple path= s in multi path case.=C2=A0


=C2=A0

On the latter case, there was good bit of discussion on ho= w well multiple DSCP markings on a single 5-tuple would work in the context= of WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=C2=A0

DSCP may not always guarantee the quality of service= as it could be remarked by the routers in between. It also depends on othe= r factors within the router eg: burst, =C2=A0packet rate etc . So the appli= cation priority can get lost.=C2=A0 Based on the QUIC stream priority, netw= ork elements could remark the DSCP value to take a better path.

So, I recommended you = look at the document because it treats the problem of having a single five(= or six)-tuple flow have different markings.=C2=A0 Evidently, your basic ans= wer is to replace the current flow-state management with a different view o= f the flow ("session"), using the stream id as a demultiplexing s= ignal.=C2=A0 You then wish to have a marking for the session.=C2=A0
One of the design goals of QUIC is that it be deployable on the= Internet as it exists, rather than relying on features which must be intro= duced into the network to support it.=C2=A0 This effort seems to run counte= r to that design goal as well.
=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">
We are= not proposing any remarking of the QUIC stream priority, but that it will = remain the same. We can add authentication to make sure the fields are in t= act. Also in DSCP case a single flow will usually be given the same priorit= y. In this case, the single flow/session can be given different priorities = on a per stream basis.

<= div>
Of course, there is a potential silly state here if th= e session-state aware network elements do something on one signal and their= non-session-state peers act on a different signal; at best, you'd have= to scrub and re-mark to avoid that.=C2=A0 Given that, I fail to see why th= e multiple-markings within a flow approach of RFC 7657 doesn't work at = least as well, at least for the Internet as currently deployed.

regards,

Ted
=C2=A0
Thanks,
Abilash


Though pointing primarily at RTP flows multiplexed using BU= NDLE, I suspect many of the lessons learned would apply to your efforts, wh= ether you used DSCP or a different marking.
<= blockquote type=3D"cite">

regards,=

Ted



On Thu, Jan 5, 2017 a= t 7:34 AM, Ritesh Mukherjee <rmukherjee@128technology.com&g= t; wrote:

Hi = Team,

=C2=A0

We = recently published draft-abilash-quic-network-00 which proposes a change to= the QUIC protocol header that will allow network elements to prioritize st= reams in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received some v= ery positive comments from some members but wanted to solicit feedback from= the larger community. Please provide your comments/feedback/recommendations as necessary:

=C2=A0

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Htmlized:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-abilash= -quic-network-00

=C2=A0

<= p class=3D"MsoNormal">Thank you in advance!<= u>

=C2=A0

Ritesh<= /span>

=C2=A0





--001a114348b60d10b8054564f345-- From nobody Thu Jan 5 22:23: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 2FA7012998D for ; Thu, 5 Jan 2017 22:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aApsnDl_s9yz for ; Thu, 5 Jan 2017 22:23:31 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F94129997 for ; Thu, 5 Jan 2017 22:23:31 -0800 (PST) Received: from [192.168.3.100] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F38D022E1F3; Fri, 6 Jan 2017 01:23:18 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: QUIC Interim Meeting - registration closing, dietary requirements Date: Fri, 6 Jan 2017 17:23:14 +1100 Message-Id: <114989C2-6FCF-4C7F-B5C0-0CCE3276B325@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Lars Eggert X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Mark Nottingham List-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, 06 Jan 2017 06:23:34 -0000 Hi everyone, If you intend on participating in our upcoming interim meeting (onsite = or remotely), please register as per the arrangements page ASAP: = https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangeme= nts.md As that page states, registration closes two weeks beforehand, which is = 10 January Tokyo time -- i.e., 9 January in many North and South = American time zones. If you're registered to participate onsite and have dietary = restrictions, please send them to me by replying to this e-mail (not to = the list!) as soon as possible. Kind regards, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Jan 6 00:37: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 C3F84129AD7 for ; Fri, 6 Jan 2017 00:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 SOJuYnzawSmD for ; Fri, 6 Jan 2017 00:37:48 -0800 (PST) Received: from relais-inet.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 BFFC7128E18 for ; Fri, 6 Jan 2017 00:37:47 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id D8A50180F6B; Fri, 6 Jan 2017 09:37:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id AAC69120059; Fri, 6 Jan 2017 09:37:45 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Fri, 6 Jan 2017 09:37:45 +0100 From: To: Ritesh Mukherjee , "quic@ietf.org" Subject: RE: soliciting feedback on draft-abilash-quic-network Thread-Topic: soliciting feedback on draft-abilash-quic-network Thread-Index: AdJnaJAo7EFh+AryQuCJjvpLcGn68QAjsp6w Date: Fri, 6 Jan 2017 08:37:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DE01E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> In-Reply-To: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DE01E2OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 08:37:50 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DE01E2OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Ritesh, Thank you for sharing this draft. I appreciate the idea of exposing more information in the public QUIC heade= r for network-assistance purposes. I see this effort as a contribution to t= his charter text: =3D=3D Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258. =3D=3D I understand this is a -00. More discussion is required to justify to what = extent the proposed priority field and moving the stream ID to the public h= eader will be of help. Thank you for initiating this work. Cheers, Med De : QUIC [mailto:quic-bounces@ietf.org] De la part de Ritesh Mukherjee Envoy=E9 : jeudi 5 janvier 2017 16:35 =C0 : quic@ietf.org Objet : soliciting feedback on draft-abilash-quic-network Hi Team, We recently published draft-abilash-quic-network-00 which proposes a change= to the QUIC protocol header that will allow network elements to prioritize= streams in QUIC packets, divert high priority streams to low loss paths, a= nd adjust packet pacing on a per stream basis. We have already received som= e very positive comments from some members but wanted to solicit feedback f= rom the larger community. Please provide your comments/feedback/recommendat= ions as necessary: URL: https://www.ietf.org/internet-drafts/draft-abilash-quic-net= work-00.txt Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 Thank you in advance! Ritesh --_000_787AE7BB302AE849A7480A190F8B933009DE01E2OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Ritesh,

 

Thank you for sharing this draf= t.

 

I appreciate the idea of exposi= ng more information in the public QUIC header for network-assistance purpos= es. I see this effort as a contribution to this charter text:  

 

=3D=3D

Current practices for network m= anagement of transport protocols

include the ability to apply ac= cess control lists (ACLs), hashing of

flows for equal-cost multipath = routing (ECMP), directional signaling

of flows, signaling of flow set= up and teardown, and the ability to

export information about flows = for accounting purposes. The QUIC

protocol need not be defined to= enable each of these abilities, or

enable them in the same way as = they are enabled by TCP when used

with TLS 1.3, but the working g= roup must consider the impact of the

protocol on network management = practices, reflecting the tensions

described in RFC 7258.

=3D=3D

 

I understand this is a -00. Mor= e discussion is required to justify to what extent the proposed priority fi= eld and moving the stream ID to the public header will be of help.

 

Thank you for initiating this w= ork.

 

Cheers,

Med

 

De : QUIC= [mailto:quic-bounces@ietf.org] De la part de Ritesh Mukherjee
Envoy=E9 : jeudi 5 janvier 2017 16:35
=C0 : quic@ietf.org
Objet : soliciting feedback on draft-abilash-quic-network<= /o:p>

 

Hi Team,

 

We recently published draft-abilash-quic-network-00 whi= ch proposes a change to the QUIC protocol header that will allow network el= ements to prioritize streams in QUIC packets, divert high priority streams to low loss paths, and adjust packet pacing on a per= stream basis. We have already received some very positive comments from so= me members but wanted to solicit feedback from the larger community. Please= provide your comments/feedback/recommendations as necessary:

 

URL:    =         https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt<= o:p>

Htmlized:   &= nbsp;   https://tools.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in advance!

 

Ritesh

 

--_000_787AE7BB302AE849A7480A190F8B933009DE01E2OPEXCLILMA3corp_-- From nobody Fri Jan 6 05:00: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 ADDC9129418 for ; Fri, 6 Jan 2017 05:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 K49cdPEWpVRS for ; Fri, 6 Jan 2017 05:00:06 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 D885D128AC9 for ; Fri, 6 Jan 2017 05:00:05 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id k15so307555586qtg.3 for ; Fri, 06 Jan 2017 05:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=cOeXgv/gGj+u+uNMQJrPG7Ah5lbtxvFVMejLJRdeS9g=; b=X6MXCL8t6Dowo6ER62QfufYgsAyie3m2TbNWfN8zUV2oo20p+fSq0NAifGmesNIKGb RuSBCAbugnTMgcDdrTPv0P1vrPk0L3KM7H7IBIpOmHorf7LKgu1nAfNcMBLwD5T5Epb7 Xev2JJq616ijL/saEKpQ6vMuhRjHOFy459mF8B+EMliYcSof55LdSDp4LoFzHEYNtEup Dv/i3Fq0LiE0waGZmoHKatc9xpEPjD5HylbTIO0ifTCw0i0zJ7chveOkvGg4Mjs6FCmj s5M0p0X128hpAgJNOYGBsoTzDozIeoj4/21lVLPtBYwT2GYiosFQXMe0pvC6RSIGLrAv jiiQ== 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 :message-id:references:to; bh=cOeXgv/gGj+u+uNMQJrPG7Ah5lbtxvFVMejLJRdeS9g=; b=lkq0NR+GUaGHXyM9PeiUTgxF4y/Wqtrnqzqzy5JjoL4bqjSEVIOxrTShUF8rtfSsEY C8xmyiGuTzj9cr0j5MH/Qqm1hkoRw3tjXxHzvoWKncn4eZJmNvf2Fkx/Ji2e1XTLYjs/ KUECShOO3+DaRGxDZlcNWKTwXjsz+ip1i3oUsOyA4/EwXeje+qMNOP1KI7FrrVy02cU/ JwNPqaS5dg3QCA19m1Xo+JjWTS9NDVTPXaJQc+/4iOmAT+x8ZxaKmYZqinIlAqoxwlBc pb6mbFQishSrzpx9fwpLEmShRN8UMHzzroxedaqiqrHDgRjGYArgu2bfzsMmB5QYt5OK aOTQ== X-Gm-Message-State: AIkVDXJyis+/y7IWZXC/seiiZ04eD16X0d1rHaDCYemJ9cjVCgA54bcuSfvxOZUfweTiELCY X-Received: by 10.200.55.178 with SMTP id d47mr73421034qtc.60.1483707604936; Fri, 06 Jan 2017 05:00:04 -0800 (PST) Received: from [10.0.3.102] ([172.85.41.102]) by smtp.gmail.com with ESMTPSA id e33sm6087713qtb.31.2017.01.06.05.00.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Jan 2017 05:00:04 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_87EBE811-9DCB-493B-912D-9597B33E89FF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: Date: Fri, 6 Jan 2017 08:00:03 -0500 Message-Id: References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:00:08 -0000 --Apple-Mail=_87EBE811-9DCB-493B-912D-9597B33E89FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ted, > On Jan 5, 2017, at 7:08 PM, Ted Hardie wrote: >=20 > Reply in-line. >=20 > On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon = > wrote: > Hey Ted, >=20 > Thanks for your feedback. Please see replies inline : >=20 >> On Jan 5, 2017, at 2:57 PM, Ted Hardie > wrote: >>=20 >> Howdy, >>=20 >> Forgive the top posting, but this seems to be a bit of meta-question. = If I read your draft correctly, you are suggesting that QUIC expose = stream identifiers and associate them with a priority, so that on-path = devices may move certain streams onto higher priority paths or otherwise = give variable quality of service. >=20 > That is one use case yes. The on-path devices can provide quality of = services on a per stream basis.=20 >=20 >>=20 >> For this to work correctly, though, the basic aim of multiplexing = seems to be changed as you could not multiplex streams into the same = packet, even if they have the same desired network treatment. At that = level of isolation, independent QUIC connections may suit your use cases = just as well (if, indeed, you would choose QUIC at all). If that is the = required level of independence, why does opening different connections = not work as well? >=20 > Using stream1, the connection gets established and the headers get = exchanged using stream 3. Opening multiple connections would incur more = latency for the connection setup. So with one QUIC connection, multiple = streams can leverage the same connection without taking the hit of the = connection establishment latency for each stream. >=20 > With 0RTT, this is probably not an issue for a long-lived flows, and = it has to be compared to the cost for application mechanics to make sure = that each packet contains elements from only a single stream. For a = multiplexing protocol, the latter seems fundamentally sub-optimal. Sure. I agree for long lived flows. I am not sure if the use case for = QUIC is going to be limited to the current applications or will be = extended going forward. Our idea was to get application view of the = network on a per stream basis - provides better debugging , analytics = and any protocol specific assistance that could be provided. Yes the = details of the latter are important I understand. > =20 >=20 >>=20 >> It's also not clear why you need that level of independence. At the = very least, your description makes it seem that you could multiplex = streams whose desired network treatment is the same. And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a packet). >=20 > Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection.=20 >=20 >=20 > So, "building the QUIC state machine in the network elements" doesn't = mean much absent a knowledge of what those network elements are going to = do with the state. The use case that you mentioned originally, path = selection for network treatment, doesn't actually require that the = on-path elements distinguish among streams that require like treatment. = It simply requires that the requested network treatment be visible. = Given that multiplexing streams that require like network treatment = works with the multiplexed design of QUIC, I'm still unclear why you = want to insist on such a strict independence. Sure. The state machine can help implement some security features, = ensure the client and server are following the protocol specifics and = can also implement rate limit per stream. The idea here was to get this = started and going forward work with the charter to continue to improve = on this. Yes - the network treatment being visible would solve the = prioritization.=20 >=20 >> Instead, you would only need to expose the desired network = treatment for a specific packet. Why is that not enough to meet the = need and why, if that is the case, would differentiated DSCP markings = not meet your needs? >=20 > Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection. >=20 > Your draft says this: >=20 > However, session aware routers will have a flow per > stream. Hence the packet rate can be adjusted on a per stream = basis > and not for the whole connection. > Once again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular. A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow. You are = motivating the change in QUIC in order to achieve that for session aware = routers, but without addressing the loss of other basic QUIC design = features. Sorry that may have been confusing.. Yes the current routers have no way = to do that. The statement assumes that the fields have been exposed. Yes = - our motivation is to have submissions for every QUIC sessions that can = be seen in network elements. > =20 > Also, the stream priority would be used to send among multiple paths = in multi path case.=20 >=20 >=20 > =20 >>=20 >> On the latter case, there was good bit of discussion on how well = multiple DSCP markings on a single 5-tuple would work in the context of = WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=20 >=20 > DSCP may not always guarantee the quality of service as it could be = remarked by the routers in between. It also depends on other factors = within the router eg: burst, packet rate etc . So the application = priority can get lost. Based on the QUIC stream priority, network = elements could remark the DSCP value to take a better path. >=20 > So, I recommended you look at the document because it treats the = problem of having a single five(or six)-tuple flow have different = markings. Evidently, your basic answer is to replace the current = flow-state management with a different view of the flow ("session"), = using the stream id as a demultiplexing signal. You then wish to have a = marking for the session. =20 Sure. Will take a look at the document. >=20 > One of the design goals of QUIC is that it be deployable on the = Internet as it exists, rather than relying on features which must be = introduced into the network to support it. This effort seems to run = counter to that design goal as well. Ofcourse. The design goal makes sense - else the protocol cannot evolve = at all ! Our proposal is an optional feature which could be used if the = network elements can support it. > =20 > We are not proposing any remarking of the QUIC stream priority, but = that it will remain the same. We can add authentication to make sure the = fields are in tact. Also in DSCP case a single flow will usually be = given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis. >=20 >=20 > Of course, there is a potential silly state here if the session-state = aware network elements do something on one signal and their = non-session-state peers act on a different signal; at best, you'd have = to scrub and re-mark to avoid that. Given that, I fail to see why the = multiple-markings within a flow approach of RFC 7657 doesn't work at = least as well, at least for the Internet as currently deployed. Things could be made to work - I need to read the RFC. But our view is = that any application traffic could be assisted by the network elements. = Aforementioned, this would help with analytics, debugging etc. = Applications could be written with network in mind giving more granular = control.(not just the priority). Ff there are network elements that = support it, the applications can make use of it. I understand your = concerns as we don=E2=80=99t have results to back this for QUIC. Thanks Abilash=20 >=20 > regards, >=20 > Ted > =20 > Thanks, > Abilash >=20 >=20 >> Though pointing primarily at RTP flows multiplexed using BUNDLE, I = suspect many of the lessons learned would apply to your efforts, whether = you used DSCP or a different marking. >>=20 >> regards, >>=20 >> Ted >>=20 >>=20 >>=20 >> On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee = > = wrote: >> Hi Team, >>=20 >> =20 >>=20 >> We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary: >>=20 >> =20 >>=20 >> URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt = >> Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 = >> =20 >>=20 >> Thank you in advance! >>=20 >> =20 >>=20 >> Ritesh >>=20 >> =20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_87EBE811-9DCB-493B-912D-9597B33E89FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ted,


On = Jan 5, 2017, at 7:08 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Reply in-line.

On Thu, = Jan 5, 2017 at 3:38 PM, Abilash Menon <amenon@128technology.com> wrote:
Hey Ted,

Thanks for your = feedback. Please see replies inline :

On Jan 5, 2017, at 2:57 PM, Ted = Hardie <ted.ietf@gmail.com> wrote:

Howdy,

Forgive the top posting, but this seems to be a bit of = meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, = so that on-path devices may move certain streams onto higher priority = paths or otherwise give variable quality of service.

That is one use case yes. The = on-path devices can provide quality of services on a per stream = basis. 


For this to work = correctly, though, the basic aim of multiplexing seems to be changed as = you could not multiplex streams into the same packet, even if they have = the same desired network treatment.  At that level of isolation, = independent QUIC connections may suit your use cases just as well (if, = indeed, you would choose QUIC at all).  If that is the required = level of independence, why does opening different connections not work = as well?

Using stream1, the connection = gets established and the headers get exchanged using stream 3. Opening = multiple connections would incur more latency for the connection setup. = So with one QUIC connection, multiple streams can leverage the same = connection without taking the hit of the connection establishment = latency for each stream.

With 0RTT, this is = probably not an issue for a long-lived flows, and it has to be compared = to the cost for application mechanics to make sure that each packet = contains elements from only a single stream.  For a multiplexing = protocol, the latter seems fundamentally sub-optimal.

Sure. I agree for long lived flows. I am not sure = if the use case for QUIC is going to be limited to the current = applications or will be extended going forward. Our idea was to get = application view of the network on a per stream basis - provides better = debugging , analytics and any protocol specific assistance that could be = provided. Yes the details of the latter are important I = understand.

 


It's= also not clear why you need that level of independence. At the very = least, your description makes it seem that you could multiplex streams = whose desired network treatment is the same.  And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a = packet).

Stream id being exposed would help build QUIC = state machine in the network elements for each stream as mentioned in = the draft. The packet pacing mechanism will also benefit from this as it = can be done a per stream basis and not for the whole = connection. 


So, "building the QUIC state machine in = the network elements" doesn't mean much absent a knowledge of what those = network elements are going to do with the state.  The use case that = you mentioned originally, path selection for network treatment, doesn't = actually require that the on-path elements distinguish among streams = that require like treatment.  It simply requires that the requested = network treatment be visible.  Given that multiplexing streams that = require like network treatment works with the multiplexed design of = QUIC, I'm still unclear why you want to insist on such a strict = independence.

Sure. The state machine can help implement some = security features, ensure the client and server are following the = protocol specifics and can also implement rate limit per stream. The = idea here was to get this started and going forward work with the = charter to continue to improve on this. Yes - the network treatment = being visible would solve the prioritization. 



  Instead, you would only = need to expose the desired network treatment for a specific = packet.  Why is that not enough to meet the need and why, if that = is the case, would differentiated DSCP markings not meet your needs?

Yes. Network treatment of a = packet (priority) is definitely needed. Stream id being exposed would = help build QUIC state machine in the network elements for each stream as = mentioned in the draft. The packet pacing mechanism will also benefit = from this as it can be done a per stream basis and not for the whole = connection.

Your draft says this:

   However, session aware =
routers will have a flow per
   stream.  Hence the packet rate can be adjusted on a per stream basis
   and not for the whole connection.
Once = again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular.  A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow.  You = are motivating the change in QUIC in order to achieve that for session = aware routers, but without addressing the loss of other basic QUIC = design features.

Sorry that may have been confusing.. Yes the = current routers have no way to do that. The statement assumes that the = fields have been exposed. Yes - our motivation is to have submissions = for every QUIC sessions that can be seen in network = elements.

 
= Also, the stream priority would be used to send among multiple paths in = multi path case. 


 

On the latter case, there was good bit of discussion on how = well multiple DSCP markings on a single 5-tuple would work in the = context of WEBRTC; if you have not read RFC 7657, I would suggest doing = so, along with draft-ietf-tsvwg-rtcweb-qos.  =

DSCP may not always guarantee = the quality of service as it could be remarked by the routers in = between. It also depends on other factors within the router eg: burst, =  packet rate etc . So the application priority can get lost.  = Based on the QUIC stream priority, network elements could remark the = DSCP value to take a better path. =

So, I recommended you look at the = document because it treats the problem of having a single five(or = six)-tuple flow have different markings.  Evidently, your basic = answer is to replace the current flow-state management with a different = view of the flow ("session"), using the stream id as a demultiplexing = signal.  You then wish to have a marking for the session. 

Sure. Will take a look at the document.


One of the design goals of QUIC is that it be deployable on = the Internet as it exists, rather than relying on features which must be = introduced into the network to support it.  This effort seems to = run counter to that design goal as well.

Ofcourse. The design goal makes sense - else the = protocol cannot evolve at all ! Our proposal is an optional feature = which could be used if the network elements can support it.

 
We= are not proposing any remarking of the QUIC stream priority, but that = it will remain the same. We can add authentication to make sure the = fields are in tact. Also in DSCP case a single flow will usually be = given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis.

Of course, there is a potential silly state here if the = session-state aware network elements do something on one signal and = their non-session-state peers act on a different signal; at best, you'd = have to scrub and re-mark to avoid that.  Given that, I fail to see = why the multiple-markings within a flow approach of RFC 7657 doesn't = work at least as well, at least for the Internet as currently = deployed.

Things could be made to work - I need to read the = RFC. But our view is that any application traffic could be assisted by = the network elements.  Aforementioned,  this would help with = analytics, debugging etc. Applications could be written with network in = mind giving more granular control.(not just the priority). Ff there are = network elements that support it, the applications can make use of it. I = understand your concerns as we don=E2=80=99t have results to back this = for QUIC.

Thanks
Abilash 


regards,

Ted
 
Thanks,
Abilash


Though pointing primarily at RTP flows multiplexed using = BUNDLE, I suspect many of the lessons learned would apply to your = efforts, whether you used DSCP or a different = marking.
regards,

Ted



On Thu, Jan 5, 2017 at 7:34 AM, = Ritesh Mukherjee <rmukherjee@128technology.com> wrote:

Hi Team,

 

We recently published = draft-abilash-quic-network-00 which proposes a change to the QUIC = protocol header that will allow network elements to prioritize streams = in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received = some very positive comments from some members but wanted to solicit = feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary:

 

URL:       &= nbsp;    https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Htmlized:       = https://tools.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in advance!<= font color=3D"#888888" class=3D"">

<= font color=3D"#888888" class=3D"">

 

Ritesh

 




= --Apple-Mail=_87EBE811-9DCB-493B-912D-9597B33E89FF-- From nobody Fri Jan 6 05:16: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 0E7D212948E for ; Fri, 6 Jan 2017 05:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 dpJNQzGmfYB1 for ; Fri, 6 Jan 2017 05:16:52 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAA6129482 for ; Fri, 6 Jan 2017 05:16:52 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id x49so12278598qtc.2 for ; Fri, 06 Jan 2017 05:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LWpXYUN/zUuiYN8oLTwDoFxw6zVJCVbYpo/SdSCFFHI=; b=z9pCbNfbXSlM3jnQP86OAU9WgwZDXRHS45/ERP1n5TX2FOvwyMzMcFsQuzb31ONXae iNDBHim5WwGkyF4j2g4YZXid+J6+A+PbtCFWaLA5Ms8h5Bdje+R1+MB32rVJ49chGn0j GRbcRU1ofWUVFeMndZPWVHJ3rLH7Nf5ikeXmM7BhlvzGhsXbl4mKkqxa7VO7p7y+vgD0 MhA5DwZ6xyNzkRKVkfv7fzDm8ACs8qyzybiowcGa2vgP7+oj2Jk/bgPzyenVukGqUC/N fMEZYrS47jYDg+/evAYM1P7TM3omz3orEyEYobJOSEPKh5b5tZAgM/qHqLUvx3QlVCUA LTGg== 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 :message-id:references:to; bh=LWpXYUN/zUuiYN8oLTwDoFxw6zVJCVbYpo/SdSCFFHI=; b=RUq0YFSWgOEBdnK7so8+16xVsF9t5LeXIUHQXtNXIil7pXBZmxpngsquerSdxGtd3J CjPqYCdBhfpxH+2oaHe9SbLM5W6t2urgADUO4NxzY2RZIytNf45kbVYRybRfNNMMRR8b yxX/8Y4gNLFKPSPBLg3XZLr43ytnvqhxfqDbUmRdkoTV44TK8H212x2nEz802/BsbXui xMf2EZriyarWnALrElnIewOEjFL7YPjGruq+RhhftBIA2M35/ylzkr0mNIIFrriQ1HLS 3VIhVpB+A70YOSYXkGGJrPu8ld9UnN8jW0QDNO1k8W2U+eWf4j28PFNkA3e0B9E/GB1y FaPQ== X-Gm-Message-State: AIkVDXKpwQQRaNQWY4emaWiuh9fl04X4Ifh3zf3lj5JAHqursdXU6jWnDHdOoTv9B/l37YFF X-Received: by 10.200.39.82 with SMTP id h18mr9393304qth.290.1483708611319; Fri, 06 Jan 2017 05:16:51 -0800 (PST) Received: from [10.0.3.102] ([172.85.41.102]) by smtp.gmail.com with ESMTPSA id 83sm43278099qky.43.2017.01.06.05.16.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Jan 2017 05:16:50 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0E713E0C-3892-41CF-BBCA-7AA9B0D09E5B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: Date: Fri, 6 Jan 2017 08:16:49 -0500 Message-Id: <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , Ted Hardie , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:16:54 -0000 --Apple-Mail=_0E713E0C-3892-41CF-BBCA-7AA9B0D09E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jana, Thank you for reviewing. Please see inline : > On Jan 5, 2017, at 10:52 PM, Jana Iyengar wrote: >=20 > Hi, >=20 > Thanks for writing up the draft -- as Patrick notes, it's helpful to = have something concrete to discuss. >=20 > I have a number of thoughts as I catch up on this thread, but I have a = high-order one: have you considered proposing this draft for HTTP/2? = Given that the use of streams is basically the same for HTTP/2 and HTTP = over QUIC, I would expect that signaling stream IDs and priorities for = HTTP/2 should be similar. Why not propose it for HTTP/2? We did not consider that, but we certainly could. Thank you for the = suggestion. >=20 > There are a significant number of engineering issues with doing = priorities per stream, the most significant one being the one that = Christian points out: that congestion control and loss detection will = need to be per-stream, defeating a major rationale for stream = multiplexing. That is a show-stopper, in my opinion. You'd have the same = troubles with TCP and HTTP/2. So if you consider packet pacing with multiple streams, the latency of = one stream need not be affected by another if one specific stream gets = affected. Yes this would need per stream congestion control - it looks = like you done want to have that granular control here. So is there any = network assistance you would like the protocol to get if the network = elements can support it. If so , please let us know - we would like to = understand.=20 >=20 > I don't think prioritizing streams by network elements makes good = engineering sense. Prioritization could certainly help streams. That could use the RFC7657 = which Ted had mentioned, but our approach was to leverage the QUIC = protocol itself to use priority and get more granular view of the = network using stream ids. We will see if we can get some useful results. Thanks, Abilash >=20 > - jana >=20 >=20 > On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie > wrote: > Reply in-line. >=20 > On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon = > wrote: > Hey Ted, >=20 > Thanks for your feedback. Please see replies inline : >=20 >> On Jan 5, 2017, at 2:57 PM, Ted Hardie > wrote: >>=20 >> Howdy, >>=20 >> Forgive the top posting, but this seems to be a bit of meta-question. = If I read your draft correctly, you are suggesting that QUIC expose = stream identifiers and associate them with a priority, so that on-path = devices may move certain streams onto higher priority paths or otherwise = give variable quality of service. >=20 > That is one use case yes. The on-path devices can provide quality of = services on a per stream basis.=20 >=20 >>=20 >> For this to work correctly, though, the basic aim of multiplexing = seems to be changed as you could not multiplex streams into the same = packet, even if they have the same desired network treatment. At that = level of isolation, independent QUIC connections may suit your use cases = just as well (if, indeed, you would choose QUIC at all). If that is the = required level of independence, why does opening different connections = not work as well? >=20 > Using stream1, the connection gets established and the headers get = exchanged using stream 3. Opening multiple connections would incur more = latency for the connection setup. So with one QUIC connection, multiple = streams can leverage the same connection without taking the hit of the = connection establishment latency for each stream. >=20 > With 0RTT, this is probably not an issue for a long-lived flows, and = it has to be compared to the cost for application mechanics to make sure = that each packet contains elements from only a single stream. For a = multiplexing protocol, the latter seems fundamentally sub-optimal. > =20 >=20 >>=20 >> It's also not clear why you need that level of independence. At the = very least, your description makes it seem that you could multiplex = streams whose desired network treatment is the same. And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a packet). >=20 > Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection.=20 >=20 >=20 > So, "building the QUIC state machine in the network elements" doesn't = mean much absent a knowledge of what those network elements are going to = do with the state. The use case that you mentioned originally, path = selection for network treatment, doesn't actually require that the = on-path elements distinguish among streams that require like treatment. = It simply requires that the requested network treatment be visible. = Given that multiplexing streams that require like network treatment = works with the multiplexed design of QUIC, I'm still unclear why you = want to insist on such a strict independence. >=20 >> Instead, you would only need to expose the desired network = treatment for a specific packet. Why is that not enough to meet the = need and why, if that is the case, would differentiated DSCP markings = not meet your needs? >=20 > Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection. >=20 > Your draft says this: >=20 > However, session aware routers will have a flow per > stream. Hence the packet rate can be adjusted on a per stream = basis > and not for the whole connection. > Once again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular. A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow. You are = motivating the change in QUIC in order to achieve that for session aware = routers, but without addressing the loss of other basic QUIC design = features. > =20 > Also, the stream priority would be used to send among multiple paths = in multi path case.=20 >=20 >=20 > =20 >>=20 >> On the latter case, there was good bit of discussion on how well = multiple DSCP markings on a single 5-tuple would work in the context of = WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=20 >=20 > DSCP may not always guarantee the quality of service as it could be = remarked by the routers in between. It also depends on other factors = within the router eg: burst, packet rate etc . So the application = priority can get lost. Based on the QUIC stream priority, network = elements could remark the DSCP value to take a better path. >=20 > So, I recommended you look at the document because it treats the = problem of having a single five(or six)-tuple flow have different = markings. Evidently, your basic answer is to replace the current = flow-state management with a different view of the flow ("session"), = using the stream id as a demultiplexing signal. You then wish to have a = marking for the session. =20 >=20 > One of the design goals of QUIC is that it be deployable on the = Internet as it exists, rather than relying on features which must be = introduced into the network to support it. This effort seems to run = counter to that design goal as well. > =20 > We are not proposing any remarking of the QUIC stream priority, but = that it will remain the same. We can add authentication to make sure the = fields are in tact. Also in DSCP case a single flow will usually be = given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis. >=20 >=20 > Of course, there is a potential silly state here if the session-state = aware network elements do something on one signal and their = non-session-state peers act on a different signal; at best, you'd have = to scrub and re-mark to avoid that. Given that, I fail to see why the = multiple-markings within a flow approach of RFC 7657 doesn't work at = least as well, at least for the Internet as currently deployed. >=20 > regards, >=20 > Ted > =20 > Thanks, > Abilash >=20 >=20 >> Though pointing primarily at RTP flows multiplexed using BUNDLE, I = suspect many of the lessons learned would apply to your efforts, whether = you used DSCP or a different marking. >>=20 >> regards, >>=20 >> Ted >>=20 >>=20 >>=20 >> On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee = > = wrote: >> Hi Team, >>=20 >> =20 >>=20 >> We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary: >>=20 >> =20 >>=20 >> URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt = >> Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 = >> =20 >>=20 >> Thank you in advance! >>=20 >> =20 >>=20 >> Ritesh >>=20 >> =20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_0E713E0C-3892-41CF-BBCA-7AA9B0D09E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jana,

Thank= you for reviewing. Please see inline :

On = Jan 5, 2017, at 10:52 PM, Jana Iyengar <jri@google.com> = wrote:

Hi,

Thanks for writing up the draft -- as Patrick notes, it's = helpful to have something concrete to discuss.

I have a number of thoughts as I catch = up on this thread, but I have a high-order one: have you considered = proposing this draft for HTTP/2? Given that the use of streams is = basically the same for HTTP/2 and HTTP over QUIC, I would expect that = signaling stream IDs and priorities for HTTP/2 should be similar. Why = not propose it for HTTP/2?

We did not consider that, but we certainly could. = Thank you for the suggestion.


There are a significant = number of engineering issues with doing priorities per stream, the most = significant one being the one that Christian points out: that congestion = control and loss detection will need to be per-stream, defeating a major = rationale for stream multiplexing. That is a show-stopper, in my = opinion. You'd have the same troubles with TCP and = HTTP/2.

So = if you consider packet pacing with multiple streams, the latency of one = stream need not be affected by another if one specific stream gets = affected. Yes this would need per stream congestion control - it looks = like you done want to have that granular control here. So is there any = network assistance you would like the protocol to get if the network = elements can support it. If so , please let us know - we would like to = understand. 

I don't think prioritizing streams by = network elements makes good engineering = sense.

Prioritization could certainly help streams. That = could use the RFC7657 which Ted had mentioned, but our approach was to = leverage the QUIC protocol itself to use priority and get more granular = view of the network using stream ids. We will see if we can get some = useful results.

Thanks,
Abilash



- jana


On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Reply in-line.

On Thu, Jan 5, = 2017 at 3:38 PM, Abilash Menon <amenon@128technology.com> wrote:
Hey Ted,

Thanks for your feedback. Please see replies inline = :

On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Howdy,

Forgive the top posting, but this seems to be a bit of = meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, = so that on-path devices may move certain streams onto higher priority = paths or otherwise give variable quality of service.

That is one use case yes. The = on-path devices can provide quality of services on a per stream = basis. 


For this to work correctly, though, the basic aim of = multiplexing seems to be changed as you could not multiplex streams into = the same packet, even if they have the same desired network = treatment.  At that level of isolation, independent QUIC = connections may suit your use cases just as well (if, indeed, you would = choose QUIC at all).  If that is the required level of = independence, why does opening different connections not work as = well?

Using stream1, the connection = gets established and the headers get exchanged using stream 3. Opening = multiple connections would incur more latency for the connection setup. = So with one QUIC connection, multiple streams can leverage the same = connection without taking the hit of the connection establishment = latency for each stream.

With 0RTT, this = is probably not an issue for a long-lived flows, and it has to be = compared to the cost for application mechanics to make sure that each = packet contains elements from only a single stream.  For a = multiplexing protocol, the latter seems fundamentally sub-optimal.
 

It's also not = clear why you need that level of independence. At the very least, your = description makes it seem that you could multiplex streams whose desired = network treatment is the same.  And, if you did multiplex streams = with the same desired network treatment, there seems to be no need at = all to expose the stream identifiers (after all, you might have more = than one stream in a packet).

Stream id being exposed would = help build QUIC state machine in the network elements for each stream as = mentioned in the draft. The packet pacing mechanism will also benefit = from this as it can be done a per stream basis and not for the whole = connection. 


So, "building the QUIC state = machine in the network elements" doesn't mean much absent a knowledge of = what those network elements are going to do with the state.  The = use case that you mentioned originally, path selection for network = treatment, doesn't actually require that the on-path elements = distinguish among streams that require like treatment.  It simply = requires that the requested network treatment be visible.  Given = that multiplexing streams that require like network treatment works with = the multiplexed design of QUIC, I'm still unclear why you want to insist = on such a strict independence.

  Instead, you would only need to expose the desired = network treatment for a specific packet.  Why is that not enough to = meet the need and why, if that is the case, would differentiated DSCP = markings not meet your needs?

Yes. Network treatment of a = packet (priority) is definitely needed. Stream id being exposed would = help build QUIC state machine in the network elements for each stream as = mentioned in the draft. The packet pacing mechanism will also benefit = from this as it can be done a per stream basis and not for the whole = connection.

Your draft says this:

   However, session aware =
routers will have a flow per
   stream.  Hence the packet rate can be adjusted on a per stream basis
   and not for the whole connection.
Once = again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular.  A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow.  You = are motivating the change in QUIC in order to achieve that for session = aware routers, but without addressing the loss of other basic QUIC = design features.
 
Also, the stream priority would be used to = send among multiple paths in multi path case. 


 

On the latter case, = there was good bit of discussion on how well multiple DSCP markings on a = single 5-tuple would work in the context of WEBRTC; if you have not read = RFC 7657, I would suggest doing so, along with = draft-ietf-tsvwg-rtcweb-qos. 

DSCP may not = always guarantee the quality of service as it could be remarked by the = routers in between. It also depends on other factors within the router = eg: burst,  packet rate etc . So the application priority can get = lost.  Based on the QUIC stream priority, network elements could = remark the DSCP value to take a better path. =

So, I recommended you look at = the document because it treats the problem of having a single five(or = six)-tuple flow have different markings.  Evidently, your basic = answer is to replace the current flow-state management with a different = view of the flow ("session"), using the stream id as a demultiplexing = signal.  You then wish to have a marking for the session. 

One of the design goals = of QUIC is that it be deployable on the Internet as it exists, rather = than relying on features which must be introduced into the network to = support it.  This effort seems to run counter to that design goal = as well.
 
We are not proposing any remarking of the = QUIC stream priority, but that it will remain the same. We can add = authentication to make sure the fields are in tact. Also in DSCP case a = single flow will usually be given the same priority. In this case, the = single flow/session can be given different priorities on a per stream = basis.


Of course, there is a potential silly state here = if the session-state aware network elements do something on one signal = and their non-session-state peers act on a different signal; at best, = you'd have to scrub and re-mark to avoid that.  Given that, I fail = to see why the multiple-markings within a flow approach of RFC 7657 = doesn't work at least as well, at least for the Internet as currently = deployed.

regards,

Ted
 
Thanks,
Abilash


Though pointing primarily at RTP flows multiplexed using = BUNDLE, I suspect many of the lessons learned would apply to your = efforts, whether you used DSCP or a different = marking.
regards,

Ted



On Thu, Jan 5, 2017 at 7:34 AM, = Ritesh Mukherjee <rmukherjee@128technology.com> wrote:

Hi Team,

 

We recently published = draft-abilash-quic-network-00 which proposes a change to the QUIC = protocol header that will allow network elements to prioritize streams = in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received = some very positive comments from some members but wanted to solicit = feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary:

 

URL:   &nbs= p;        https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Htmlized:   = ;    https://tools.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in advance!

 

Ritesh

 





= --Apple-Mail=_0E713E0C-3892-41CF-BBCA-7AA9B0D09E5B-- From nobody Mon Jan 9 12:15:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64912959E for ; Mon, 9 Jan 2017 12:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 Tq2x4LplKFNf for ; Mon, 9 Jan 2017 12:15:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A3312959D for ; Mon, 9 Jan 2017 12:15:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEC81000; Mon, 09 Jan 2017 20:15:24 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Jan 2017 20:15:23 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Mon, 9 Jan 2017 12:15:18 -0800 From: Lin Han To: "'Abilash Menon'" , Jana Iyengar Subject: RE: soliciting feedback on draft-abilash-quic-network Thread-Topic: soliciting feedback on draft-abilash-quic-network Thread-Index: AQHSaB8j7EFh+AryQuCJjvpLcGn68aEwl6wg Date: Mon, 9 Jan 2017 20:15:18 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> In-Reply-To: <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.117] Content-Type: multipart/alternative; boundary="_000_1D30AF33624CDD4A99E8C395069A2A162B86F57Cdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.5873EF5D.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fb0ae679fdc49ba71db0861a3474db12 Archived-At: Cc: Ritesh Mukherjee , Ted Hardie , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:15:30 -0000 --_000_1D30AF33624CDD4A99E8C395069A2A162B86F57Cdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Abilash I have a question which might be related to this topic. >From the point of view of network device, we want to know and also wish tha= t the QUIC could support the signaling for the network device along the pat= h. This is for the QoS enhancement consideration in the future. Marking priori= ty is not enough for provisioning a device. The lesson from TCP is its rigidity for the extension. It would be nice tha= t QUIC has such elastic from the beginning of the design. Thanks Lin From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Abilash Menon Sent: Friday, January 06, 2017 5:17 AM To: Jana Iyengar Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network Jana, Thank you for reviewing. Please see inline : On Jan 5, 2017, at 10:52 PM, Jana Iyengar > wrote: Hi, Thanks for writing up the draft -- as Patrick notes, it's helpful to have s= omething concrete to discuss. I have a number of thoughts as I catch up on this thread, but I have a high= -order one: have you considered proposing this draft for HTTP/2? Given that= the use of streams is basically the same for HTTP/2 and HTTP over QUIC, I = would expect that signaling stream IDs and priorities for HTTP/2 should be = similar. Why not propose it for HTTP/2? We did not consider that, but we certainly could. Thank you for the suggest= ion. There are a significant number of engineering issues with doing priorities = per stream, the most significant one being the one that Christian points ou= t: that congestion control and loss detection will need to be per-stream, d= efeating a major rationale for stream multiplexing. That is a show-stopper,= in my opinion. You'd have the same troubles with TCP and HTTP/2. So if you consider packet pacing with multiple streams, the latency of one = stream need not be affected by another if one specific stream gets affected= . Yes this would need per stream congestion control - it looks like you don= e want to have that granular control here. So is there any network assistan= ce you would like the protocol to get if the network elements can support i= t. If so , please let us know - we would like to understand. I don't think prioritizing streams by network elements makes good engineeri= ng sense. Prioritization could certainly help streams. That could use the RFC7657 whi= ch Ted had mentioned, but our approach was to leverage the QUIC protocol it= self to use priority and get more granular view of the network using stream= ids. We will see if we can get some useful results. Thanks, Abilash - jana On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie > wrote: Reply in-line. On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon > wrote: Hey Ted, Thanks for your feedback. Please see replies inline : On Jan 5, 2017, at 2:57 PM, Ted Hardie > wrote: Howdy, Forgive the top posting, but this seems to be a bit of meta-question. If I= read your draft correctly, you are suggesting that QUIC expose stream iden= tifiers and associate them with a priority, so that on-path devices may mov= e certain streams onto higher priority paths or otherwise give variable qua= lity of service. That is one use case yes. The on-path devices can provide quality of servic= es on a per stream basis. For this to work correctly, though, the basic aim of multiplexing seems to = be changed as you could not multiplex streams into the same packet, even if= they have the same desired network treatment. At that level of isolation,= independent QUIC connections may suit your use cases just as well (if, ind= eed, you would choose QUIC at all). If that is the required level of indep= endence, why does opening different connections not work as well? Using stream1, the connection gets established and the headers get exchange= d using stream 3. Opening multiple connections would incur more latency for= the connection setup. So with one QUIC connection, multiple streams can le= verage the same connection without taking the hit of the connection establi= shment latency for each stream. With 0RTT, this is probably not an issue for a long-lived flows, and it has= to be compared to the cost for application mechanics to make sure that eac= h packet contains elements from only a single stream. For a multiplexing p= rotocol, the latter seems fundamentally sub-optimal. It's also not clear why you need that level of independence. At the very le= ast, your description makes it seem that you could multiplex streams whose = desired network treatment is the same. And, if you did multiplex streams w= ith the same desired network treatment, there seems to be no need at all to= expose the stream identifiers (after all, you might have more than one str= eam in a packet). Stream id being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing mecha= nism will also benefit from this as it can be done a per stream basis and n= ot for the whole connection. So, "building the QUIC state machine in the network elements" doesn't mean = much absent a knowledge of what those network elements are going to do with= the state. The use case that you mentioned originally, path selection for= network treatment, doesn't actually require that the on-path elements dist= inguish among streams that require like treatment. It simply requires that= the requested network treatment be visible. Given that multiplexing strea= ms that require like network treatment works with the multiplexed design of= QUIC, I'm still unclear why you want to insist on such a strict independen= ce. Instead, you would only need to expose the desired network treatment for = a specific packet. Why is that not enough to meet the need and why, if tha= t is the case, would differentiated DSCP markings not meet your needs? Yes. Network treatment of a packet (priority) is definitely needed. Stream = id being exposed would help build QUIC state machine in the network element= s for each stream as mentioned in the draft. The packet pacing mechanism wi= ll also benefit from this as it can be done a per stream basis and not for = the whole connection. Your draft says this: However, session aware routers will have a flow per stream. Hence the packet rate can be adjusted on a per stream basis and not for the whole connection. Once again, this seems to run counter to the design of a multiplexed protoc= ol, and the description in the document is a bit circular. A session aware= router certainly would not have a flow per stream as QUIC is designed now;= it would have no way to create such a flow. You are motivating the change= in QUIC in order to achieve that for session aware routers, but without ad= dressing the loss of other basic QUIC design features. Also, the stream priority would be used to send among multiple paths in mul= ti path case. On the latter case, there was good bit of discussion on how well multiple D= SCP markings on a single 5-tuple would work in the context of WEBRTC; if yo= u have not read RFC 7657, I would suggest doing so, along with draft-ietf-t= svwg-rtcweb-qos. DSCP may not always guarantee the quality of service as it could be remarke= d by the routers in between. It also depends on other factors within the ro= uter eg: burst, packet rate etc . So the application priority can get lost= . Based on the QUIC stream priority, network elements could remark the DSC= P value to take a better path. So, I recommended you look at the document because it treats the problem of= having a single five(or six)-tuple flow have different markings. Evidentl= y, your basic answer is to replace the current flow-state management with a= different view of the flow ("session"), using the stream id as a demultipl= exing signal. You then wish to have a marking for the session. One of the design goals of QUIC is that it be deployable on the Internet as= it exists, rather than relying on features which must be introduced into t= he network to support it. This effort seems to run counter to that design = goal as well. We are not proposing any remarking of the QUIC stream priority, but that it= will remain the same. We can add authentication to make sure the fields ar= e in tact. Also in DSCP case a single flow will usually be given the same p= riority. In this case, the single flow/session can be given different prior= ities on a per stream basis. Of course, there is a potential silly state here if the session-state aware= network elements do something on one signal and their non-session-state pe= ers act on a different signal; at best, you'd have to scrub and re-mark to = avoid that. Given that, I fail to see why the multiple-markings within a f= low approach of RFC 7657 doesn't work at least as well, at least for the In= ternet as currently deployed. regards, Ted Thanks, Abilash Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect = many of the lessons learned would apply to your efforts, whether you used D= SCP or a different marking. regards, Ted On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee > wrote: Hi Team, We recently published draft-abilash-quic-network-00 which proposes a change= to the QUIC protocol header that will allow network elements to prioritize= streams in QUIC packets, divert high priority streams to low loss paths, a= nd adjust packet pacing on a per stream basis. We have already received som= e very positive comments from some members but wanted to solicit feedback f= rom the larger community. Please provide your comments/feedback/recommendat= ions as necessary: URL: https://www.ietf.org/internet-drafts/draft-abilash-quic-net= work-00.txt Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 Thank you in advance! Ritesh --_000_1D30AF33624CDD4A99E8C395069A2A162B86F57Cdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Abilash

 <= /p>

I have a question which m= ight be related to this topic.

 <= /p>

From the point of view of= network device, we want to know and also wish that the QUIC could support = the signaling for the network device along the path.

This is for the QoS enhan= cement consideration in the future. Marking priority is not enough for prov= isioning a device.

The lesson from TCP is it= s rigidity for the extension. It would be nice that QUIC has such elastic f= rom the beginning of the design.

 <= /p>

Thanks<= /p>

 <= /p>

Lin

 <= /p>

From: QUIC [ma= ilto:quic-bounces@ietf.org] On Behalf Of Abilash Menon
Sent: Friday, January 06, 2017 5:17 AM
To: Jana Iyengar
Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on draft-abilash-quic-network<= /o:p>

 

Jana,

 

Thank you for reviewing. Please see inline :

 

On Jan 5, 2017, at 10:52 PM, Jana Iyengar <jri@google.com> wrote:

 

Hi,

 

Thanks for writing up the draft -- as Patrick notes,= it's helpful to have something concrete to discuss.

 

I have a number of thoughts as I catch up on this th= read, but I have a high-order one: have you considered proposing this draft= for HTTP/2? Given that the use of streams is basically the same for HTTP/2= and HTTP over QUIC, I would expect that signaling stream IDs and priorities for HTTP/2 should be similar. Why= not propose it for HTTP/2?

 

We did not consider that, but we certainly could. Th= ank you for the suggestion.



 

There are a significant number of engineering issues= with doing priorities per stream, the most significant one being the one t= hat Christian points out: that congestion control and loss detection will n= eed to be per-stream, defeating a major rationale for stream multiplexing. That is a show-stopper, in my opi= nion. You'd have the same troubles with TCP and HTTP/2.

 

So if you consider packet pacing with multiple strea= ms, the latency of one stream need not be affected by another if one specif= ic stream gets affected. Yes this would need per stream congestion control = - it looks like you done want to have that granular control here. So is there any network assistance you would l= ike the protocol to get if the network elements can support it. If so , ple= ase let us know - we would like to understand. 



 

I don't think prioritizing streams by network elemen= ts makes good engineering sense.

 

Prioritization could certainly help streams. That co= uld use the RFC7657 which Ted had mentioned, but our approach was to levera= ge the QUIC protocol itself to use priority and get more granular view of t= he network using stream ids. We will see if we can get some useful results.

 

Thanks,

Abilash

 



 

- jana

 

 

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

Reply in-line.

 

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <amenon@128techn= ology.com> wrote:

Hey Ted,

 

Thanks for your feedback. Please see replies inline = :

 

On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com>= wrote:

 

Howdy,

Forgive the top posting, but this seems to be a bit = of meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, so = that on-path devices may move certain streams onto higher priority paths or otherwise give variable quality of service.<= o:p>

 

That is one use case yes. The on-path devices can pr= ovide quality of services on a per stream basis. 



 

For this to work correctly, though, the basic aim of= multiplexing seems to be changed as you could not multiplex streams into t= he same packet, even if they have the same desired network treatment. = At that level of isolation, independent QUIC connections may suit your use cases just as well (if, indeed, you wou= ld choose QUIC at all).  If that is the required level of independence= , why does opening different connections not work as well?

 

Using stream1, the connection gets established and t= he headers get exchanged using stream 3. Opening multiple connections would= incur more latency for the connection setup. So with one QUIC connection, = multiple streams can leverage the same connection without taking the hit of the connection establishment lat= ency for each stream.

 

With 0RTT, this is probably not an issue for a long-= lived flows, and it has to be compared to the cost for application mechanic= s to make sure that each packet contains elements from only a single stream= .  For a multiplexing protocol, the latter seems fundamentally sub-optimal.

 




It's also not clear why you need that level of independence. At the very le= ast, your description makes it seem that you could multiplex streams whose = desired network treatment is the same.  And, if you did multiplex stre= ams with the same desired network treatment, there seems to be no need at all to expose the stream identifiers (after a= ll, you might have more than one stream in a packet).

 

Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the draft. = The packet pacing mechanism will also benefit from this as it can be done a= per stream basis and not for the whole connection. 

 

 

So, "building the QUIC state machine in the net= work elements" doesn't mean much absent a knowledge of what those netw= ork elements are going to do with the state.  The use case that you me= ntioned originally, path selection for network treatment, doesn't actually require that the on-path elements distinguish among strea= ms that require like treatment.  It simply requires that the requested= network treatment be visible.  Given that multiplexing streams that r= equire like network treatment works with the multiplexed design of QUIC, I'm still unclear why you want to insist on su= ch a strict independence.

 

  Instead, you would only need to expose the de= sired network treatment for a specific packet.  Why is that not enough= to meet the need and why, if that is the case, would differentiated DSCP m= arkings not meet your needs?

 

Yes. Network treatment of a packet (priority) is def= initely needed. Stream id being exposed would help build QUIC state machine= in the network elements for each stream as mentioned in the draft. The pac= ket pacing mechanism will also benefit from this as it can be done a per stream basis and not for the whole conne= ction.

 

Your draft says this:= 

   However, session aware routers will have a flow per<=
/o:p>
   stream.  Hence the packet rate can be adjusted on a =
per stream basis
   and not for the whole connection.

Once again, this seems to run counter to the design = of a multiplexed protocol, and the description in the document is a bit cir= cular.  A session aware router certainly would not have a flow per str= eam as QUIC is designed now; it would have no way to create such a flow.  You are motivating the change in QUIC = in order to achieve that for session aware routers, but without addressing = the loss of other basic QUIC design features.

 

Also, the stream priority would be used to send amon= g multiple paths in multi path case. 

 


 

 

On the latter case, there was good bit of discussion= on how well multiple DSCP markings on a single 5-tuple would work in the c= ontext of WEBRTC; if you have not read RFC 7657, I would suggest doing so, = along with draft-ietf-tsvwg-rtcweb-qos. 

 

DSCP may not always guarantee the quality of service= as it could be remarked by the routers in between. It also depends on othe= r factors within the router eg: burst,  packet rate etc . So the appli= cation priority can get lost.  Based on the QUIC stream priority, network elements could remark the DSCP value to = take a better path.

 

So, I recommended you= look at the document because it treats the problem of having a single five= (or six)-tuple flow have different markings.  Evidently, your basic an= swer is to replace the current flow-state management with a different view of the flow ("session"), using = the stream id as a demultiplexing signal.  You then wish to have a mar= king for the session. 

One of the design goals of QUIC is that it be deploy= able on the Internet as it exists, rather than relying on features which mu= st be introduced into the network to support it.  This effort seems to= run counter to that design goal as well.

 

We are not proposing any remarking of the QUIC strea= m priority, but that it will remain the same. We can add authentication to = make sure the fields are in tact. Also in DSCP case a single flow will usua= lly be given the same priority. In this case, the single flow/session can be given different priorities on a = per stream basis.

 

 

Of course, there is a= potential silly state here if the session-state aware network elements do = something on one signal and their non-session-state peers act on a differen= t signal; at best, you'd have to scrub and re-mark to avoid that.  Given that, I fail to see why the multipl= e-markings within a flow approach of RFC 7657 doesn't work at least as well= , at least for the Internet as currently deployed.

regards,

Ted

 

Thanks,

Abilash

 

 

Though pointing primarily at RTP flows multiplexed u= sing BUNDLE, I suspect many of the lessons learned would apply to your effo= rts, whether you used DSCP or a different marking.

 

regards,

Ted

 

 

On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee <= ;rmukherj= ee@128technology.com> wrote:

Hi Team,

 

We recently published draft-abilash-quic-network-00 which proposes= a change to the QUIC protocol header that will allow network elements to prioritize streams in QUIC packets, divert high priority strea= ms to low loss paths, and adjust packet pacing on a per stream basis. We ha= ve already received some very positive comments from some members but wante= d to solicit feedback from the larger community. Please provide your comments/feedback/recommendations as necess= ary:

 

URL:            https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt<= o:p>

Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in advance!

 

Ritesh

 

 

 

 

 

 

--_000_1D30AF33624CDD4A99E8C395069A2A162B86F57Cdfweml501mbb_-- From nobody Mon Jan 9 14:05: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 5D0411295F0 for ; Mon, 9 Jan 2017 14:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 hZLugNpLmFhY for ; Mon, 9 Jan 2017 14:05:11 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218D2127ABE for ; Mon, 9 Jan 2017 14:05:11 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id a20so156677355qkc.1 for ; Mon, 09 Jan 2017 14:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=204LByLjFghZ6djCvRfZInXD4fXmUWwMLFwL5HtNOjw=; b=ESSEHT8I47qmuYHOC70lAvG8LGx5vCxDiA4pZZxKrUp0EYKuIX3Loo8tGtgX82clyq CfeED/CxEROxbjF3Qui2KhCsqd1jhyXTzNtSpYMbkiGqfuBmB4LdfvWpYxKXSBov4/wx 5Bx0JhoN+TD5beci1NtC2H/sLKojgqWqSCZF47/WRPS3+vpr3PEjuMxSgjh+X2cUiCG+ bk4HVldpBtq8us1S67WTeug3JMRIrcgLIwDbn2jsZyGt7tVTH2Ia7iOo5RZBD6Xom5Zy hJ+mKlgk4e3OyrArweSGw4EggVMGalVbnkzz4xwPnsKKIg54uFlmz+qkTrANnxpTEwJp JKlQ== 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 :message-id:references:to; bh=204LByLjFghZ6djCvRfZInXD4fXmUWwMLFwL5HtNOjw=; b=miJ+7jWdGV2eoymeEzr0ewsx2amjvwF9bdL1D+4jTB+61sGnGKdGIoDK+GHIitUhse bhK3DDHCoRskfsMuW7NXuPGYsRJI3noePtI3xu2VGkJuco1nGP2P0dpfZTDqfmO5ugst WrS8IJ7SSgZVGgmMFbIoAExfRR5JxtLc6Wltxe6ZUN1xqGfMCbOBneBHmzkAlCVtltVt 3rfoI5iSLg8R32N3gUpKCeNWjz6aW4BkermHtCMPbGsQ3tt2u9bdqsGHiNeShsO+xdGT 8+Vxl2ec8BHs9Y+4QQkW+V3mbABwQ+tNXxf1fVeFuZ+hf6qzb4Eg86pMmH8cjS/zqU9a kSWg== X-Gm-Message-State: AIkVDXJ5H3xlbJAHEBCx4XGgxzFgsmN/LCo+7A5k5wgRbXW4cfCeqbJKMZZWSqgqnglhVi8F X-Received: by 10.55.65.82 with SMTP id o79mr85164273qka.136.1483999510228; Mon, 09 Jan 2017 14:05:10 -0800 (PST) Received: from [10.0.2.25] ([172.85.50.34]) by smtp.gmail.com with ESMTPSA id r65sm1331679qkd.41.2017.01.09.14.05.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jan 2017 14:05:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_944488B9-92F6-4F57-A496-788E3E67DD8F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> Date: Mon, 9 Jan 2017 17:05:08 -0500 Message-Id: <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> To: Lin Han X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , Jana Iyengar , Ted Hardie , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:05:13 -0000 --Apple-Mail=_944488B9-92F6-4F57-A496-788E3E67DD8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lin, We had suggested priority and streamed as a starting point to get more = network aware details from the application. When you say signaling - are = you indicating signaling to setup the network elements to start looking = for QUIC packets or for something else. Please clarify. Thanks, Abilash > On Jan 9, 2017, at 3:15 PM, Lin Han wrote: >=20 > Hi, Abilash > =20 > I have a question which might be related to this topic. > =20 > =46rom the point of view of network device, we want to know and also = wish that the QUIC could support the signaling for the network device = along the path. > This is for the QoS enhancement consideration in the future. Marking = priority is not enough for provisioning a device. > The lesson from TCP is its rigidity for the extension. It would be = nice that QUIC has such elastic from the beginning of the design. > =20 > Thanks > =20 > Lin > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Abilash Menon > Sent: Friday, January 06, 2017 5:17 AM > To: Jana Iyengar > Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG > Subject: Re: soliciting feedback on draft-abilash-quic-network > =20 > Jana, > =20 > Thank you for reviewing. Please see inline : > =20 > On Jan 5, 2017, at 10:52 PM, Jana Iyengar > wrote: > =20 > Hi, > =20 > Thanks for writing up the draft -- as Patrick notes, it's helpful to = have something concrete to discuss. > =20 > I have a number of thoughts as I catch up on this thread, but I have a = high-order one: have you considered proposing this draft for HTTP/2? = Given that the use of streams is basically the same for HTTP/2 and HTTP = over QUIC, I would expect that signaling stream IDs and priorities for = HTTP/2 should be similar. Why not propose it for HTTP/2? > =20 > We did not consider that, but we certainly could. Thank you for the = suggestion. >=20 >=20 > =20 > There are a significant number of engineering issues with doing = priorities per stream, the most significant one being the one that = Christian points out: that congestion control and loss detection will = need to be per-stream, defeating a major rationale for stream = multiplexing. That is a show-stopper, in my opinion. You'd have the same = troubles with TCP and HTTP/2. > =20 > So if you consider packet pacing with multiple streams, the latency of = one stream need not be affected by another if one specific stream gets = affected. Yes this would need per stream congestion control - it looks = like you done want to have that granular control here. So is there any = network assistance you would like the protocol to get if the network = elements can support it. If so , please let us know - we would like to = understand.=20 >=20 >=20 > =20 > I don't think prioritizing streams by network elements makes good = engineering sense. > =20 > Prioritization could certainly help streams. That could use the = RFC7657 which Ted had mentioned, but our approach was to leverage the = QUIC protocol itself to use priority and get more granular view of the = network using stream ids. We will see if we can get some useful results. > =20 > Thanks, > Abilash > =20 >=20 >=20 > =20 > - jana > =20 > =20 > On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie > wrote: > Reply in-line. > =20 > On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon = > wrote: > Hey Ted, > =20 > Thanks for your feedback. Please see replies inline : > =20 > On Jan 5, 2017, at 2:57 PM, Ted Hardie > wrote: > =20 > Howdy, >=20 > Forgive the top posting, but this seems to be a bit of meta-question. = If I read your draft correctly, you are suggesting that QUIC expose = stream identifiers and associate them with a priority, so that on-path = devices may move certain streams onto higher priority paths or otherwise = give variable quality of service. > =20 > That is one use case yes. The on-path devices can provide quality of = services on a per stream basis.=20 >=20 >=20 > =20 > For this to work correctly, though, the basic aim of multiplexing = seems to be changed as you could not multiplex streams into the same = packet, even if they have the same desired network treatment. At that = level of isolation, independent QUIC connections may suit your use cases = just as well (if, indeed, you would choose QUIC at all). If that is the = required level of independence, why does opening different connections = not work as well? > =20 > Using stream1, the connection gets established and the headers get = exchanged using stream 3. Opening multiple connections would incur more = latency for the connection setup. So with one QUIC connection, multiple = streams can leverage the same connection without taking the hit of the = connection establishment latency for each stream. > =20 > With 0RTT, this is probably not an issue for a long-lived flows, and = it has to be compared to the cost for application mechanics to make sure = that each packet contains elements from only a single stream. For a = multiplexing protocol, the latter seems fundamentally sub-optimal. > =20 >=20 >=20 >=20 > It's also not clear why you need that level of independence. At the = very least, your description makes it seem that you could multiplex = streams whose desired network treatment is the same. And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a packet). > =20 > Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection.=20 > =20 > =20 > So, "building the QUIC state machine in the network elements" doesn't = mean much absent a knowledge of what those network elements are going to = do with the state. The use case that you mentioned originally, path = selection for network treatment, doesn't actually require that the = on-path elements distinguish among streams that require like treatment. = It simply requires that the requested network treatment be visible. = Given that multiplexing streams that require like network treatment = works with the multiplexed design of QUIC, I'm still unclear why you = want to insist on such a strict independence. > =20 > Instead, you would only need to expose the desired network treatment = for a specific packet. Why is that not enough to meet the need and why, = if that is the case, would differentiated DSCP markings not meet your = needs? > =20 > Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection. > =20 > Your draft says this: >=20 > However, session aware routers will have a flow per > stream. Hence the packet rate can be adjusted on a per stream = basis > and not for the whole connection. > Once again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular. A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow. You are = motivating the change in QUIC in order to achieve that for session aware = routers, but without addressing the loss of other basic QUIC design = features. > =20 > Also, the stream priority would be used to send among multiple paths = in multi path case.=20 > =20 >=20 > =20 > =20 > On the latter case, there was good bit of discussion on how well = multiple DSCP markings on a single 5-tuple would work in the context of = WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=20 > =20 > DSCP may not always guarantee the quality of service as it could be = remarked by the routers in between. It also depends on other factors = within the router eg: burst, packet rate etc . So the application = priority can get lost. Based on the QUIC stream priority, network = elements could remark the DSCP value to take a better path. > =20 > So, I recommended you look at the document because it treats the = problem of having a single five(or six)-tuple flow have different = markings. Evidently, your basic answer is to replace the current = flow-state management with a different view of the flow ("session"), = using the stream id as a demultiplexing signal. You then wish to have a = marking for the session.=20 >=20 > One of the design goals of QUIC is that it be deployable on the = Internet as it exists, rather than relying on features which must be = introduced into the network to support it. This effort seems to run = counter to that design goal as well. > =20 > We are not proposing any remarking of the QUIC stream priority, but = that it will remain the same. We can add authentication to make sure the = fields are in tact. Also in DSCP case a single flow will usually be = given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis. > =20 > =20 > Of course, there is a potential silly state here if the session-state = aware network elements do something on one signal and their = non-session-state peers act on a different signal; at best, you'd have = to scrub and re-mark to avoid that. Given that, I fail to see why the = multiple-markings within a flow approach of RFC 7657 doesn't work at = least as well, at least for the Internet as currently deployed. >=20 > regards, >=20 > Ted > =20 > Thanks, > Abilash > =20 > =20 > Though pointing primarily at RTP flows multiplexed using BUNDLE, I = suspect many of the lessons learned would apply to your efforts, whether = you used DSCP or a different marking. > =20 > regards, >=20 > Ted > =20 >=20 > =20 > On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee = > = wrote: > Hi Team, > =20 > We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary:=20 > =20 >=20 > URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt = > Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 = > =20 > Thank you in advance! > =20 > Ritesh --Apple-Mail=_944488B9-92F6-4F57-A496-788E3E67DD8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Lin,

We = had suggested priority and streamed as a starting point to get more = network aware details from the application. When you say signaling - are = you indicating signaling to setup the network elements to start looking = for QUIC packets or for something else. Please clarify.

Thanks,
Abilash

On Jan 9, 2017, at 3:15 PM, Lin = Han <Lin.Han@huawei.com> wrote:

Hi, Abilash
 
I have a question which = might be related to this topic.
 
=46rom the point of = view of network device, we want to know and also wish that the QUIC = could support the signaling for the network device along the path.
This is for the QoS enhancement = consideration in the future. Marking priority is not enough for = provisioning a device.
The= lesson from TCP is its rigidity for the extension. It would be nice = that QUIC has such elastic from the beginning of the design.
 
Thanks
 
Lin
 
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Abilash = Menon
Sent: Friday, January 06, 2017 = 5:17 AM
To: Jana Iyengar
Cc: Ritesh Mukherjee; Ted = Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on = draft-abilash-quic-network
 
Jana,
 
Thank you for reviewing. Please see inline :
 
On Jan 5, 2017, at = 10:52 PM, Jana Iyengar <jri@google.com> wrote:
 
Hi,
 
Thanks for writing up the draft -- as Patrick notes, = it's helpful to have something concrete to discuss.
 
I have a number of thoughts as I catch up = on this thread, but I have a high-order one: have you considered = proposing this draft for HTTP/2? Given that the use of streams is = basically the same for HTTP/2 and HTTP over QUIC, I would expect that = signaling stream IDs and priorities for HTTP/2 should be similar. Why = not propose it for HTTP/2?
 
We did not consider that, but we certainly could. = Thank you for the suggestion.


 
There are a significant number of engineering issues = with doing priorities per stream, the most significant one being the one = that Christian points out: that congestion control and loss detection = will need to be per-stream, defeating a major rationale for stream = multiplexing. That is a show-stopper, in my opinion. You'd have the same = troubles with TCP and HTTP/2.
 
So if you consider packet pacing with multiple = streams, the latency of one stream need not be affected by another if = one specific stream gets affected. Yes this would need per stream = congestion control - it looks like you done want to have that granular = control here. So is there any network assistance you would like the = protocol to get if the network elements can support it. If so , please = let us know - we would like to understand. 


 
I don't think prioritizing streams by network = elements makes good engineering sense.
 
Prioritization could certainly help streams. That = could use the RFC7657 which Ted had mentioned, but our approach was to = leverage the QUIC protocol itself to use priority and get more granular = view of the network using stream ids. We will see if we can get some = useful results.
 
Thanks,
Abilash
 


 
- jana
 
 
On Thu, Jan 5, 2017 = at 4:08 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Reply in-line.
 
On Thu, Jan 5, 2017 = at 3:38 PM, Abilash Menon <amenon@128technology.com> wrote:
Hey Ted,
 
Thanks for your feedback. Please see replies inline = :
 
On = Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com>= wrote:
 

Howdy,

Forgive the top posting, but this seems to be a bit of = meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, = so that on-path devices may move certain streams onto higher priority = paths or otherwise give variable quality of service.
 
That is one use case yes. The on-path devices can = provide quality of services on a per stream basis. 


 
For this to work correctly, though, the basic aim of = multiplexing seems to be changed as you could not multiplex streams into = the same packet, even if they have the same desired network = treatment.  At that level of isolation, independent QUIC = connections may suit your use cases just as well (if, indeed, you would = choose QUIC at all).  If that is the required level of = independence, why does opening different connections not work as = well?
 
Using stream1, the connection gets established and = the headers get exchanged using stream 3. Opening multiple connections = would incur more latency for the connection setup. So with one QUIC = connection, multiple streams can leverage the same connection without = taking the hit of the connection establishment latency for each = stream.
 
With 0RTT, this is probably not an issue for a = long-lived flows, and it has to be compared to the cost for application = mechanics to make sure that each packet contains elements from only a = single stream.  For a multiplexing protocol, the latter seems = fundamentally sub-optimal.
 



It's = also not clear why you need that level of independence. At the very = least, your description makes it seem that you could multiplex streams = whose desired network treatment is the same.  And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a packet).
 
Stream id being exposed would help build QUIC state machine = in the network elements for each stream as mentioned in the draft. The = packet pacing mechanism will also benefit from this as it can be done a = per stream basis and not for the whole connection. 
 
 
So, "building the QUIC state machine in the network = elements" doesn't mean much absent a knowledge of what those network = elements are going to do with the state.  The use case that you = mentioned originally, path selection for network treatment, doesn't = actually require that the on-path elements distinguish among streams = that require like treatment.  It simply requires that the requested = network treatment be visible.  Given that multiplexing streams that = require like network treatment works with the multiplexed design of = QUIC, I'm still unclear why you want to insist on such a strict = independence.
 
  Instead, you would only need to = expose the desired network treatment for a specific packet.  Why is = that not enough to meet the need and why, if that is the case, would = differentiated DSCP markings not meet your needs?
 
Yes. Network treatment of a packet (priority) is = definitely needed. Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the = draft. The packet pacing mechanism will also benefit from this as it can = be done a per stream basis and not for the whole connection.
 

Your draft says this:

   However, session aware routers =
will have a flow per
   stream.  Hence the packet rate can be =
adjusted on a per stream basis
   and not for the whole =
connection.
Once again, this seems to run counter to = the design of a multiplexed protocol, and the description in the = document is a bit circular.  A session aware router certainly would = not have a flow per stream as QUIC is designed now; it would have no way = to create such a flow.  You are motivating the change in QUIC in = order to achieve that for session aware routers, but without addressing = the loss of other basic QUIC design features.
 
Also, the stream priority would be used to send among = multiple paths in multi path case. 
 

 
 
On the latter case, there was good bit of discussion = on how well multiple DSCP markings on a single 5-tuple would work in the = context of WEBRTC; if you have not read RFC 7657, I would suggest doing = so, along with draft-ietf-tsvwg-rtcweb-qos. 
 
DSCP may not always guarantee the quality of service = as it could be remarked by the routers in between. It also depends on = other factors within the router eg: burst,  packet rate etc . So = the application priority can get lost.  Based on the QUIC stream = priority, network elements could remark the DSCP value to take a better = path.
 

So, I recommended you look at the document because it = treats the problem of having a single five(or six)-tuple flow have = different markings.  Evidently, your basic answer is to replace the = current flow-state management with a different view of the flow = ("session"), using the stream id as a demultiplexing signal.  You = then wish to have a marking for the session. 

One of the design goals of QUIC is that it be deployable on = the Internet as it exists, rather than relying on features which must be = introduced into the network to support it.  This effort seems to = run counter to that design goal as well.
 
We are not proposing any remarking of the QUIC stream = priority, but that it will remain the same. We can add authentication to = make sure the fields are in tact. Also in DSCP case a single flow will = usually be given the same priority. In this case, the single = flow/session can be given different priorities on a per stream = basis.
 
 

Of course, there is a potential silly state here if the = session-state aware network elements do something on one signal and = their non-session-state peers act on a different signal; at best, you'd = have to scrub and re-mark to avoid that.  Given that, I fail to see = why the multiple-markings within a flow approach of RFC 7657 doesn't = work at least as well, at least for the Internet as currently = deployed.

regards,

Ted
 
Thanks,
Abilash
 
 
Though pointing = primarily at RTP flows multiplexed using BUNDLE, I suspect many of the = lessons learned would apply to your efforts, whether you used DSCP or a = different marking.
 

regards,

Ted

 

 
On Thu, Jan 5, 2017 at 7:34 AM, Ritesh = Mukherjee <rmukherjee@128technology.com> wrote:
Hi Team,
 
We recently published = draft-abilash-quic-network-00 which proposes a change to the QUIC = protocol header that will allow network elements to prioritize streams = in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received = some very positive comments from some members but wanted to solicit = feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary: 

 

URL:          &n= bsp; https://www.ietf.org/internet-drafts/draft-abilash-quic-network= -00.txt

Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

 
Thank you in advance!
 
Ritesh

= --Apple-Mail=_944488B9-92F6-4F57-A496-788E3E67DD8F-- From nobody Tue Jan 10 07:33: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 EAEEE129466 for ; Tue, 10 Jan 2017 07:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 ptwaZaEmrt8P for ; Tue, 10 Jan 2017 07:33:41 -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 E601A129CF4 for ; Tue, 10 Jan 2017 07:33:40 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l75so38160646ywb.0 for ; Tue, 10 Jan 2017 07:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4QIW4WQdWo15148m7nOMdOxKB4/zRkYzG/+z5qJk2Vk=; b=BP9OJWakf4dKb03AaPuQYWkFmLgSPbcXyIxjBEFQxO/NoAMREAzq0HQi750DJUZD4R FSzeyoXIezJpxbEe4R3Nh0CU8XzCsA3oMbcZzbbNT/6OJmvF8OUhCu4VAzHvi4IQMax0 tIHYLBhXBpTx0QPZKJs3252u/KetLAY0umWxtynrGQaKz0l8+Svw5+scJZOAeIpGmEbP cmSRIixjX1Ilx1oTc2wCOkTilh6Q0xhu3E8mzShdyBsW/dUPHDWjoW0TP16pDFUxXyQ1 eMCMrGyKEWqgyPWdXR0syjVUZOO5pkxwDwHkhIXfw7ENLw9V2ivXZxVgJXjb2/6oXkm7 6j5w== 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=4QIW4WQdWo15148m7nOMdOxKB4/zRkYzG/+z5qJk2Vk=; b=IF9OC2jJ3yG/h5n9LeTKCyF0i0FC35pHFbQK2O48JNBMkNa7knFicnsLGH3tDZmFlI HJ+XXnD6sjl1QQFpG9O/jM1CvWY5benl4UOvnjyUivtNlJ8Z2+q70hxlXOcL3N97yhEY 8Y53GWDcWPSnvxsH4V21Gp61l0Q3JGKS2ZLFz+8bfbRVnStTLYVQ+TK4nt7Ql69howsU t0tk8vtDQU1X7GW+szbNvBgbDlr670WMG9qE+36lcTGyoHP1LMm5d47+tMl1wlmPkTkB 2W1SegABscxO1FiEXy90UTS47i1zRZDhtXjZLSwuTOCo2VTy4kEkMqj6z73IdSc/PTnP 5l2A== X-Gm-Message-State: AIkVDXI8DZC/jV22TUsruuMfuU7bhhQLb+rVfEUbT1CuZJR5x3icWzj/hDAnko9OYBYsrpm45eJ+1QSHd2VDoS/I X-Received: by 10.13.245.199 with SMTP id e190mr3309880ywf.317.1484062419881; Tue, 10 Jan 2017 07:33:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Tue, 10 Jan 2017 07:33:19 -0800 (PST) In-Reply-To: <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> From: Ian Swett Date: Tue, 10 Jan 2017 07:33:19 -0800 Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Abilash Menon Content-Type: multipart/alternative; boundary=94eb2c032e705d65db0545bf3591 Archived-At: Cc: Ritesh Mukherjee , Jana Iyengar , Ted Hardie , IETF QUIC WG , Lin Han X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Jan 2017 15:33:44 -0000 --94eb2c032e705d65db0545bf3591 Content-Type: text/plain; charset=UTF-8 I have many of the same concerns expressed above, but one specific element of this proposal would appear to be a clear violation of the charter, which is exposing stream ids and priorities. The charter says: "This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP" HTTP/2 over TLS 1.3 does not expose these, and so as Jana mentioned, you'd have to convince the HTTP/2 working group to expose these first. On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon wrote: > Lin, > > We had suggested priority and streamed as a starting point to get more > network aware details from the application. When you say signaling - are > you indicating signaling to setup the network elements to start looking for > QUIC packets or for something else. Please clarify. > > Thanks, > Abilash > > On Jan 9, 2017, at 3:15 PM, Lin Han wrote: > > Hi, Abilash > > I have a question which might be related to this topic. > > From the point of view of network device, we want to know and also wish > that the QUIC could support the signaling for the network device along the > path. > This is for the QoS enhancement consideration in the future. Marking > priority is not enough for provisioning a device. > The lesson from TCP is its rigidity for the extension. It would be nice > that QUIC has such elastic from the beginning of the design. > > Thanks > > Lin > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Abilash Menon > *Sent:* Friday, January 06, 2017 5:17 AM > *To:* Jana Iyengar > *Cc:* Ritesh Mukherjee; Ted Hardie; IETF QUIC WG > *Subject:* Re: soliciting feedback on draft-abilash-quic-network > > Jana, > > Thank you for reviewing. Please see inline : > > > On Jan 5, 2017, at 10:52 PM, Jana Iyengar wrote: > > Hi, > > Thanks for writing up the draft -- as Patrick notes, it's helpful to have > something concrete to discuss. > > I have a number of thoughts as I catch up on this thread, but I have a > high-order one: have you considered proposing this draft for HTTP/2? Given > that the use of streams is basically the same for HTTP/2 and HTTP over > QUIC, I would expect that signaling stream IDs and priorities for HTTP/2 > should be similar. Why not propose it for HTTP/2? > > > We did not consider that, but we certainly could. Thank you for the > suggestion. > > > > There are a significant number of engineering issues with doing priorities > per stream, the most significant one being the one that Christian points > out: that congestion control and loss detection will need to be per-stream, > defeating a major rationale for stream multiplexing. That is a > show-stopper, in my opinion. You'd have the same troubles with TCP and > HTTP/2. > > So if you consider packet pacing with multiple streams, the latency of one > stream need not be affected by another if one specific stream gets > affected. Yes this would need per stream congestion control - it looks like > you done want to have that granular control here. So is there any network > assistance you would like the protocol to get if the network elements can > support it. If so , please let us know - we would like to understand. > > > > I don't think prioritizing streams by network elements makes good > engineering sense. > > Prioritization could certainly help streams. That could use the RFC7657 > which Ted had mentioned, but our approach was to leverage the QUIC protocol > itself to use priority and get more granular view of the network using > stream ids. We will see if we can get some useful results. > > Thanks, > Abilash > > > > > - jana > > > On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie wrote: > Reply in-line. > > On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon > wrote: > Hey Ted, > > Thanks for your feedback. Please see replies inline : > > > On Jan 5, 2017, at 2:57 PM, Ted Hardie wrote: > > > Howdy, > Forgive the top posting, but this seems to be a bit of meta-question. If > I read your draft correctly, you are suggesting that QUIC expose stream > identifiers and associate them with a priority, so that on-path devices may > move certain streams onto higher priority paths or otherwise give variable > quality of service. > > > That is one use case yes. The on-path devices can provide quality of > services on a per stream basis. > > > > For this to work correctly, though, the basic aim of multiplexing seems to > be changed as you could not multiplex streams into the same packet, even if > they have the same desired network treatment. At that level of isolation, > independent QUIC connections may suit your use cases just as well (if, > indeed, you would choose QUIC at all). If that is the required level of > independence, why does opening different connections not work as well? > > Using stream1, the connection gets established and the headers get > exchanged using stream 3. Opening multiple connections would incur more > latency for the connection setup. So with one QUIC connection, multiple > streams can leverage the same connection without taking the hit of the > connection establishment latency for each stream. > > With 0RTT, this is probably not an issue for a long-lived flows, and it > has to be compared to the cost for application mechanics to make sure that > each packet contains elements from only a single stream. For a > multiplexing protocol, the latter seems fundamentally sub-optimal. > > > > > > It's also not clear why you need that level of independence. At the very > least, your description makes it seem that you could multiplex streams > whose desired network treatment is the same. And, if you did multiplex > streams with the same desired network treatment, there seems to be no need > at all to expose the stream identifiers (after all, you might have more > than one stream in a packet). > > Stream id being exposed would help build QUIC state machine in the network > elements for each stream as mentioned in the draft. The packet pacing > mechanism will also benefit from this as it can be done a per stream basis > and not for the whole connection. > > > > So, "building the QUIC state machine in the network elements" doesn't mean > much absent a knowledge of what those network elements are going to do with > the state. The use case that you mentioned originally, path selection for > network treatment, doesn't actually require that the on-path elements > distinguish among streams that require like treatment. It simply requires > that the requested network treatment be visible. Given that multiplexing > streams that require like network treatment works with the multiplexed > design of QUIC, I'm still unclear why you want to insist on such a strict > independence. > > > Instead, you would only need to expose the desired network treatment for > a specific packet. Why is that not enough to meet the need and why, if > that is the case, would differentiated DSCP markings not meet your needs? > > > Yes. Network treatment of a packet (priority) is definitely needed. Stream > id being exposed would help build QUIC state machine in the network > elements for each stream as mentioned in the draft. The packet pacing > mechanism will also benefit from this as it can be done a per stream basis > and not for the whole connection. > > > > Your draft says this: > > However, session aware routers will have a flow per > > stream. Hence the packet rate can be adjusted on a per stream basis > > and not for the whole connection. > > Once again, this seems to run counter to the design of a multiplexed > protocol, and the description in the document is a bit circular. A session > aware router certainly would not have a flow per stream as QUIC is designed > now; it would have no way to create such a flow. You are motivating the > change in QUIC in order to achieve that for session aware routers, but > without addressing the loss of other basic QUIC design features. > > > Also, the stream priority would be used to send among multiple paths in > multi path case. > > > > > > > On the latter case, there was good bit of discussion on how well multiple > DSCP markings on a single 5-tuple would work in the context of WEBRTC; if > you have not read RFC 7657, I would suggest doing so, along with > draft-ietf-tsvwg-rtcweb-qos. > > > DSCP may not always guarantee the quality of service as it could be > remarked by the routers in between. It also depends on other factors within > the router eg: burst, packet rate etc . So the application priority can > get lost. Based on the QUIC stream priority, network elements could remark > the DSCP value to take a better path. > > > > So, I recommended you look at the document because it treats the problem > of having a single five(or six)-tuple flow have different markings. > Evidently, your basic answer is to replace the current flow-state > management with a different view of the flow ("session"), using the stream > id as a demultiplexing signal. You then wish to have a marking for the > session. > One of the design goals of QUIC is that it be deployable on the Internet > as it exists, rather than relying on features which must be introduced into > the network to support it. This effort seems to run counter to that design > goal as well. > > > We are not proposing any remarking of the QUIC stream priority, but that > it will remain the same. We can add authentication to make sure the fields > are in tact. Also in DSCP case a single flow will usually be given the same > priority. In this case, the single flow/session can be given different > priorities on a per stream basis. > > > > > Of course, there is a potential silly state here if the session-state > aware network elements do something on one signal and their > non-session-state peers act on a different signal; at best, you'd have to > scrub and re-mark to avoid that. Given that, I fail to see why the > multiple-markings within a flow approach of RFC 7657 doesn't work at least > as well, at least for the Internet as currently deployed. > > regards, > Ted > > > Thanks, > Abilash > > > > Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect > many of the lessons learned would apply to your efforts, whether you used > DSCP or a different marking. > > > > regards, > Ted > > > > On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < > rmukherjee@128technology.com> wrote: > Hi Team, > > We recently published draft-abilash-quic-network-00 which proposes a > change to the QUIC protocol header that will allow network elements to > prioritize streams in QUIC packets, divert high priority streams to low > loss paths, and adjust packet pacing on a per stream basis. We have already > received some very positive comments from some members but wanted to > solicit feedback from the larger community. Please provide your > comments/feedback/recommendations as necessary: > > > > URL: https://www.ietf.org/internet-drafts/ > draft-abilash-quic-network-00.txt > > Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 > > Thank you in advance! > > Ritesh > > > --94eb2c032e705d65db0545bf3591 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have many of the same concerns expressed above, but= one specific element of this proposal would appear to be a clear violation= of the charter, which is exposing stream ids and priorities.

The charter says: "This wor= k will ensure that QUIC has security and privacy=C2=A0properties that are at least as good as a stack composed of TL= S 1.3 =C2=A0using TCP"
<= div>
HTTP/2 over TLS 1.3 does no= t expose these, and so as Jana mentioned, you'd have to convince the HT= TP/2 working group to expose these first.
<= br>
On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon= <amenon@128technology.com> wrote:
Lin,

We had suggested priority and streamed as a starting point to get more n= etwork aware details from the application. When you say signaling - are you= indicating signaling to setup the network elements to start looking for QU= IC packets or for something else. Please clarify.

= Thanks,
Abilash

On Jan 9, 2017, at 3:15 PM, Lin Han <Lin.Han@huawei.com> wro= te:

=
= Hi, Abilash
=C2=A0
I have a question= which might be related to this topic.
=C2=A0
From the point of view of network device, we want to know and als= o wish that the QUIC could support the signaling for the network device alo= ng the path.
Thi= s is for the QoS enhancement consideration in the future. Marking priority = is not enough for provisioning a device.
The lesson from TCP is its rigidity for the extensio= n. It would be nice that QUIC has such elastic from the beginning of the de= sign.
=C2= =A0
Thanks<= /span>
=C2=A0
Lin
=C2=A0
From:=C2=A0QUIC [mailto:quic-bounces@ietf.org]=C2=A0On Behalf O= f=C2=A0Abilash Menon
Sent:=C2=A0Friday, January 06, 2017 5:17 AM
To:<= span class=3D"m_-560948228511432656Apple-converted-space">=C2=A0Jana= Iyengar
Cc:=C2=A0Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject= :=C2=A0Re: soliciting feedback on draft-abilash-quic-network
=C2=A0
Jana,
=C2=A0
Thank you for reviewi= ng. Please see inline :
On Jan 5, 2017, at 10:52 PM, Jana = Iyengar <jri@google.com> wrote:<= u>
=C2=A0
Hi,
=C2=A0
Thanks for wri= ting up the draft -- as Patrick notes, it's helpful to have something c= oncrete to discuss.
=C2=A0
I have a number o= f thoughts as I catch up on this thread, but I have a high-order one: have = you considered proposing this draft for HTTP/2? Given that the use of strea= ms is basically the same for HTTP/2 and HTTP over QUIC, I would expect that= signaling stream IDs and priorities for HTTP/2 should be similar. Why not = propose it for HTTP/2?
=C2=A0
We did not consider that, but we certainly could. Thank you fo= r the suggestion.


<= u>
=C2=A0
There are a significant number of= engineering issues with doing priorities per stream, the most significant = one being the one that Christian points out: that congestion control and lo= ss detection will need to be per-stream, defeating a major rationale for st= ream multiplexing. That is a show-stopper, in my opinion. You'd have th= e same troubles with TCP and HTTP/2.
<= div>
=C2=A0
So if you consider packet pacing with multiple streams, the la= tency of one stream need not be affected by another if one specific stream = gets affected. Yes this would need per stream congestion control - it looks= like you done want to have that granular control here. So is there any net= work assistance you would like the protocol to get if the network elements = can support it. If so , please let us know - we would like to understand.= =C2=A0


=C2=A0
I don't think prioritizing streams by ne= twork elements makes good engineering sense.
=C2=A0
Prioritization could certainly help streams. That could= use the RFC7657 which Ted had mentioned, but our approach was to leverage = the QUIC protocol itself to use priority and get more granular view of the = network using stream ids. We will see if we can get some useful results.=
=C2=A0
Thanks,
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">Abilash
=C2=A0


<= /u>
=C2=A0<= /div>
- jana
=C2=A0
=C2=A0
On Thu= , Jan 5, 2017 at 4:08 PM, Ted Hardie <ted.= ietf@gmail.com> wrote:
=C2= =A0
On Thu, Jan 5, 2017 at 3:38 PM,= Abilash Menon <amenon@128technology= .com> wrote:
Hey Ted,=
=C2=A0
<= /div>
Thanks for your feedback. Please see repli= es inline :
=C2= =A0
On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:<= /div>
=C2=A0
=

Howdy,

Forgive the top posting, but this seems to be a bi= t of meta-question.=C2=A0 If I read your draft correctly, you are suggestin= g that QUIC expose stream identifiers and associate them with a priority, s= o that on-path devices may move certain streams onto higher priority paths = or otherwise give variable quality of service.
=C2=A0
That is one use case yes. The on-p= ath devices can provide quality of services on a per stream basis.=C2=A0=


=
=C2=A0
For this to work correctly, though, the basic aim of mult= iplexing seems to be changed as you could not multiplex streams into the sa= me packet, even if they have the same desired network treatment.=C2=A0 At t= hat level of isolation, independent QUIC connections may suit your use case= s just as well (if, indeed, you would choose QUIC at all).=C2=A0 If that is= the required level of independence, why does opening different connections= not work as well?
=C2=A0
Using = stream1, the connection gets established and the headers get exchanged usin= g stream 3. Opening multiple connections would incur more latency for the c= onnection setup. So with one QUIC connection, multiple streams can leverage= the same connection without taking the hit of the connection establishment= latency for each stream.
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">=C2=A0
With 0RTT, this is probably not an issue for a long-lived flows, and= it has to be compared to the cost for application mechanics to make sure t= hat each packet contains elements from only a single stream.=C2=A0 For a mu= ltiplexing protocol, the latter seems fundamentally sub-optimal.<= /u>
=C2=A0
=



It's also not clear = why you need that level of independence. At the very least, your descriptio= n makes it seem that you could multiplex streams whose desired network trea= tment is the same.=C2=A0 And, if you did multiplex streams with the same de= sired network treatment, there seems to be no need at all to expose the str= eam identifiers (after all, you might have more than one stream in a packet= ).
= =C2=A0
Stream id being exposed wou= ld help build QUIC state machine in the network elements for each stream as= mentioned in the draft. The packet pacing mechanism will also benefit from= this as it can be done a per stream basis and not for the whole connection= .=C2=A0
=C2=A0<= u>
<= /u>=C2=A0
So, "building = the QUIC state machine in the network elements" doesn't mean much = absent a knowledge of what those network elements are going to do with the = state.=C2=A0 The use case that you mentioned originally, path selection for= network treatment, doesn't actually require that the on-path elements = distinguish among streams that require like treatment.=C2=A0 It simply requ= ires that the requested network treatment be visible.=C2=A0 Given that mult= iplexing streams that require like network treatment works with the multipl= exed design of QUIC, I'm still unclear why you want to insist on such a= strict independence.
= =C2=A0
=C2=A0 Instead, you would only need to expose the desired netw= ork treatment for a specific packet.=C2=A0 Why is that not enough to meet t= he need and why, if that is the case, would differentiated DSCP markings no= t meet your needs?
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">=C2=A0
Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing mecha= nism will also benefit from this as it can be done a per stream basis and n= ot for the whole connection.
=C2=A0
=

Your draft says this:

=C2=A0=C2=A0 However, session aware routers will have a flow =
per
=C2=A0=C2=A0 stream.=C2=A0 Hence the pa=
cket rate can be adjusted on a per stream basis
=C2=A0=C2=A0 and not for the whole connection.
Once again, this seems to run counter to the = design of a multiplexed protocol, and the description in the document is a = bit circular.=C2=A0 A session aware router certainly would not have a flow = per stream as QUIC is designed now; it would have no way to create such a f= low.=C2=A0 You are motivating the change in QUIC in order to achieve that f= or session aware routers, but without addressing the loss of other basic QU= IC design features.
= =C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">Also, the stream priority would be used to send among= multiple paths in multi path case.=C2=A0
=C2=A0

=C2=A0
=C2=A0
On the latter case, there was good bit of discuss= ion on how well multiple DSCP markings on a single 5-tuple would work in th= e context of WEBRTC; if you have not read RFC 7657, I would suggest doing s= o, along with draft-ietf-tsvwg-rtcweb-qos.=C2=A0
<= /div>
=C2=A0
DSCP may not always guarantee the qual= ity of service as it could be remarked by the routers in between. It also d= epends on other factors within the router eg: burst, =C2=A0packet rate etc = . So the application priority can get lost.=C2=A0 Based on the QUIC stream = priority, network elements could remark the DSCP value to take a better pat= h.
=C2=A0

So, I recommended you look at the document because it treats th= e problem of having a single five(or six)-tuple flow have different marking= s.=C2=A0 Evidently, your basic answer is to replace the current flow-state = management with a different view of the flow ("session"), using t= he stream id as a demultiplexing signal.=C2=A0 You then wish to have a mark= ing for the session.=C2=A0

One of the design goals of QUIC is that it be deployable on the Internet= as it exists, rather than relying on features which must be introduced int= o the network to support it.=C2=A0 This effort seems to run counter to that= design goal as well.
= =C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">We are not proposing any remarking of the QUIC stream= priority, but that it will remain the same. We can add authentication to m= ake sure the fields are in tact. Also in DSCP case a single flow will usual= ly be given the same priority. In this case, the single flow/session can be= given different priorities on a per stream basis.
=C2=A0
=C2=A0

Of course, there is a potential sill= y state here if the session-state aware network elements do something on on= e signal and their non-session-state peers act on a different signal; at be= st, you'd have to scrub and re-mark to avoid that.=C2=A0 Given that, I = fail to see why the multiple-markings within a flow approach of RFC 7657 do= esn't work at least as well, at least for the Internet as currently dep= loyed.

reg= ards,

Ted<= /div>
=C2=A0
Thanks,
Abilash
=C2=A0
=
=C2=A0
Th= ough pointing primarily at RTP flows multiplexed using BUNDLE, I suspect ma= ny of the lessons learned would apply to your efforts, whether you used DSC= P or a different marking.
=C2=A0

regards,

Ted

<= u>=C2=A0

On Thu, Jan 5, 2017= at 7:34 AM, Ritesh Mukherjee <r= mukherjee@128technology.com> wrote:
Hi Team,
=C2=A0
We recently published draft-abilash-quic-network-00 which = proposes a change to the QUIC protocol header that will allow network eleme= nts to prioritize streams in QUIC packets, divert high priority streams to = low loss paths, and adjust packet pacing on a per stream basis. We have alr= eady received some very positive comments from some members but wanted to s= olicit feedback from the larger community. Please provide your comments/fee= dback/recommendations as necessary:=C2=A0

=C2=A0

URL:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/inte= rnet-drafts/draft-abilash-quic-network-00.txt

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.= org/html/draft-abilash-quic-network-00

= =C2=A0
Thank you in advance!
=C2=A0
<= span style=3D"font-family:'montserrat light',serif;color:rgb(136,13= 6,136)">Ritesh
=
<= /div>

--94eb2c032e705d65db0545bf3591-- From nobody Tue Jan 10 08:27: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 DB0ED12960B for ; Tue, 10 Jan 2017 08:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 NjpNJSfqTjBS for ; Tue, 10 Jan 2017 08:26:57 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 C86481295F9 for ; Tue, 10 Jan 2017 08:26:57 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id 189so37148806pfu.3 for ; Tue, 10 Jan 2017 08:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=We3KJio5BnMsA8QCeMf+3rCOMrA0WHwkH/ekdeEf5SE=; b=QTHAi+eUfZFZuL2ugglfMXO6WlpLiTl5lCBe/fUrkbqaKAGtj/B5+/ntkKh1VllRH+ ChLlt5vCkJthpFLG3bBXm00v7w6kFkdfcXSJ3QNiLzRZUaf+CzGzZcHfpa5KaYbBPxB0 PVxxclPTcDT4S4pfdLtJTkJ45L4rbFtXsfk3g3vQnpx0s04/AUPxhDuFRMWK5hDj2A/O J1uROqymDxTWqnP9I17JyJ8tHN9u+yfvBvO9a5OLPauVaoSJPsTy97X/lUW70tcXlawv TJgbrIOkUqlO0MrpO3OoBrCNoM1lFI/mGi3m4S5WhQcEZI/1XKvOQ/xH8VrJPX0z6GwI DQYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=We3KJio5BnMsA8QCeMf+3rCOMrA0WHwkH/ekdeEf5SE=; b=JsSCQbmX5ulj6MkX49MFS27YAJLkyaRvHSnQZk03dbIB1TS6rD0GvEzZmIXNu0CoJq nzTFby1QPkO16vLCA9SXWBTijPx5Q5AR/KWFFLH1v9/6iWctLHJPEOaaYB9GXnLBxBum QAQlb8voQJMvMkN9gUoaAfYfxGDVz2AYF0amB96xWzcQQXLz9byCAthTgxIdQsotNSjU mU0gMNSL9GDOYlLa48QEWX9Klzsn4ldSE5pRRjELjRhW78AHzaNA/S5eWLFbqMGA2dlR vviW8mZxQoE90wZoULsH1m9cgPu/JKbDXKuAGKnu2CuXSEJNjhnlW3G9ivr4Jg0gAowH nelQ== X-Gm-Message-State: AIkVDXJF7FdiUjaOBwHqGgXgkgGfKQdfpZYabFITlwGjoAXaEDdp0veWhIP6FiTXUKnRKvlK X-Received: by 10.99.1.132 with SMTP id 126mr4937995pgb.129.1484065617126; Tue, 10 Jan 2017 08:26:57 -0800 (PST) Received: from DESKTOP8OQ9GIB ([69.162.16.14]) by smtp.gmail.com with ESMTPSA id 18sm6958679pgf.28.2017.01.10.08.26.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 08:26:56 -0800 (PST) From: "Ritesh Mukherjee" To: "'Ian Swett'" , "'Abilash Menon'" References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> In-Reply-To: Subject: RE: soliciting feedback on draft-abilash-quic-network Date: Tue, 10 Jan 2017 08:26:53 -0800 Message-ID: <015201d26b5e$5b3bcfb0$11b36f10$@128technology.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0153_01D26B1B.4D1D71B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHdW5MPCBQI3E7Yzcbczzhdf2tIqgGvJEeDAppKLl0Dqrj3LwGgee/KAb92KYABzqp1ywJ07BAbAf76tECgj06lgA== Content-Language: en-us Archived-At: Cc: 'Jana Iyengar' , 'Ted Hardie' , 'IETF QUIC WG' , 'Lin Han' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Jan 2017 16:27:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0153_01D26B1B.4D1D71B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Please see inline=E2=80=A6 =20 From: Ian Swett [mailto:ianswett@google.com]=20 Sent: Tuesday, January 10, 2017 7:33 AM To: Abilash Menon Cc: Lin Han ; Ritesh Mukherjee = ; Jana Iyengar ; Ted = Hardie ; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network =20 I have many of the same concerns expressed above, but one specific = element of this proposal would appear to be a clear violation of the = charter, which is exposing stream ids and priorities. =20 [Ritesh] The Stream IDs and priorities would still be authenticated. Are = there any specific attacks you are concerned about? =20 The charter says: "This work will ensure that QUIC has security and = privacy properties that are at least as good as a stack composed of TLS = 1.3 using TCP" =20 HTTP/2 over TLS 1.3 does not expose these, and so as Jana mentioned, = you'd have to convince the HTTP/2 working group to expose these first. =20 [Ritesh] There is no specific sequencing of proposing enhancements = mentioned in the charter or anywhere else. In any case we understand it = would be good to have a precedent =E2=80=93 we are considering making a = proposal in the HTTP/2 WG.=20 =20 =20 On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon > wrote: Lin, =20 We had suggested priority and streamed as a starting point to get more = network aware details from the application. When you say signaling - are = you indicating signaling to setup the network elements to start looking = for QUIC packets or for something else. Please clarify. =20 Thanks, Abilash =20 On Jan 9, 2017, at 3:15 PM, Lin Han > wrote: =20 Hi, Abilash =20 I have a question which might be related to this topic. =20 >From the point of view of network device, we want to know and also wish = that the QUIC could support the signaling for the network device along = the path. This is for the QoS enhancement consideration in the future. Marking = priority is not enough for provisioning a device. The lesson from TCP is its rigidity for the extension. It would be nice = that QUIC has such elastic from the beginning of the design. =20 Thanks =20 Lin =20 From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Abilash Menon Sent: Friday, January 06, 2017 5:17 AM To: Jana Iyengar Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network =20 Jana, =20 Thank you for reviewing. Please see inline : =20 On Jan 5, 2017, at 10:52 PM, Jana Iyengar < = jri@google.com> wrote: =20 Hi, =20 Thanks for writing up the draft -- as Patrick notes, it's helpful to = have something concrete to discuss. =20 I have a number of thoughts as I catch up on this thread, but I have a = high-order one: have you considered proposing this draft for HTTP/2? = Given that the use of streams is basically the same for HTTP/2 and HTTP = over QUIC, I would expect that signaling stream IDs and priorities for = HTTP/2 should be similar. Why not propose it for HTTP/2? =20 We did not consider that, but we certainly could. Thank you for the = suggestion. =20 =20 There are a significant number of engineering issues with doing = priorities per stream, the most significant one being the one that = Christian points out: that congestion control and loss detection will = need to be per-stream, defeating a major rationale for stream = multiplexing. That is a show-stopper, in my opinion. You'd have the same = troubles with TCP and HTTP/2. =20 So if you consider packet pacing with multiple streams, the latency of = one stream need not be affected by another if one specific stream gets = affected. Yes this would need per stream congestion control - it looks = like you done want to have that granular control here. So is there any = network assistance you would like the protocol to get if the network = elements can support it. If so , please let us know - we would like to = understand.=20 =20 =20 I don't think prioritizing streams by network elements makes good = engineering sense. =20 Prioritization could certainly help streams. That could use the RFC7657 = which Ted had mentioned, but our approach was to leverage the QUIC = protocol itself to use priority and get more granular view of the = network using stream ids. We will see if we can get some useful results. =20 Thanks, Abilash =20 =20 =20 - jana =20 =20 On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie < = ted.ietf@gmail.com> wrote: Reply in-line. =20 On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon < = amenon@128technology.com> wrote: Hey Ted, =20 Thanks for your feedback. Please see replies inline : =20 On Jan 5, 2017, at 2:57 PM, Ted Hardie < = ted.ietf@gmail.com> wrote: =20 Howdy, Forgive the top posting, but this seems to be a bit of meta-question. = If I read your draft correctly, you are suggesting that QUIC expose = stream identifiers and associate them with a priority, so that on-path = devices may move certain streams onto higher priority paths or otherwise = give variable quality of service. =20 That is one use case yes. The on-path devices can provide quality of = services on a per stream basis.=20 =20 =20 For this to work correctly, though, the basic aim of multiplexing seems = to be changed as you could not multiplex streams into the same packet, = even if they have the same desired network treatment. At that level of = isolation, independent QUIC connections may suit your use cases just as = well (if, indeed, you would choose QUIC at all). If that is the = required level of independence, why does opening different connections = not work as well? =20 Using stream1, the connection gets established and the headers get = exchanged using stream 3. Opening multiple connections would incur more = latency for the connection setup. So with one QUIC connection, multiple = streams can leverage the same connection without taking the hit of the = connection establishment latency for each stream. =20 With 0RTT, this is probably not an issue for a long-lived flows, and it = has to be compared to the cost for application mechanics to make sure = that each packet contains elements from only a single stream. For a = multiplexing protocol, the latter seems fundamentally sub-optimal. =20 =20 It's also not clear why you need that level of independence. At the very = least, your description makes it seem that you could multiplex streams = whose desired network treatment is the same. And, if you did multiplex = streams with the same desired network treatment, there seems to be no = need at all to expose the stream identifiers (after all, you might have = more than one stream in a packet). =20 Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection.=20 =20 =20 So, "building the QUIC state machine in the network elements" doesn't = mean much absent a knowledge of what those network elements are going to = do with the state. The use case that you mentioned originally, path = selection for network treatment, doesn't actually require that the = on-path elements distinguish among streams that require like treatment. = It simply requires that the requested network treatment be visible. = Given that multiplexing streams that require like network treatment = works with the multiplexed design of QUIC, I'm still unclear why you = want to insist on such a strict independence. =20 Instead, you would only need to expose the desired network treatment = for a specific packet. Why is that not enough to meet the need and why, = if that is the case, would differentiated DSCP markings not meet your = needs? =20 Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection. =20 Your draft says this: However, session aware routers will have a flow per stream. Hence the packet rate can be adjusted on a per stream basis and not for the whole connection. Once again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular. A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow. You are = motivating the change in QUIC in order to achieve that for session aware = routers, but without addressing the loss of other basic QUIC design = features. =20 Also, the stream priority would be used to send among multiple paths in = multi path case.=20 =20 =20 =20 On the latter case, there was good bit of discussion on how well = multiple DSCP markings on a single 5-tuple would work in the context of = WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=20 =20 DSCP may not always guarantee the quality of service as it could be = remarked by the routers in between. It also depends on other factors = within the router eg: burst, packet rate etc . So the application = priority can get lost. Based on the QUIC stream priority, network = elements could remark the DSCP value to take a better path. =20 So, I recommended you look at the document because it treats the problem = of having a single five(or six)-tuple flow have different markings. = Evidently, your basic answer is to replace the current flow-state = management with a different view of the flow ("session"), using the = stream id as a demultiplexing signal. You then wish to have a marking = for the session.=20 One of the design goals of QUIC is that it be deployable on the Internet = as it exists, rather than relying on features which must be introduced = into the network to support it. This effort seems to run counter to = that design goal as well. =20 We are not proposing any remarking of the QUIC stream priority, but that = it will remain the same. We can add authentication to make sure the = fields are in tact. Also in DSCP case a single flow will usually be = given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis. =20 =20 Of course, there is a potential silly state here if the session-state = aware network elements do something on one signal and their = non-session-state peers act on a different signal; at best, you'd have = to scrub and re-mark to avoid that. Given that, I fail to see why the = multiple-markings within a flow approach of RFC 7657 doesn't work at = least as well, at least for the Internet as currently deployed. regards, Ted =20 Thanks, Abilash =20 =20 Though pointing primarily at RTP flows multiplexed using BUNDLE, I = suspect many of the lessons learned would apply to your efforts, whether = you used DSCP or a different marking. =20 regards, Ted =20 =20 On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < = rmukherjee@128technology.com> = wrote: Hi Team, =20 We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary:=20 =20 URL: = = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt Htmlized: = = https://tools.ietf.org/html/draft-abilash-quic-network-00 =20 Thank you in advance! =20 Ritesh =20 =20 ------=_NextPart_000_0153_01D26B1B.4D1D71B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Please see = inline=E2=80=A6

 

From:<= /b> = Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, January = 10, 2017 7:33 AM
To: Abilash Menon = <amenon@128technology.com>
Cc: Lin Han = <Lin.Han@huawei.com>; Ritesh Mukherjee = <rmukherjee@128technology.com>; Jana Iyengar = <jri@google.com>; Ted Hardie <ted.ietf@gmail.com>; IETF QUIC = WG <quic@ietf.org>
Subject: Re: soliciting feedback on = draft-abilash-quic-network

 

I = have many of the same concerns expressed above, but one specific element = of this proposal would appear to be a clear violation of the charter, = which is exposing stream ids and priorities.

 

[Ritesh] The = Stream IDs and priorities would still be authenticated. Are there any = specific attacks you are concerned about?

 

The = charter says: "This work will = ensure that QUIC has security and privacy properties that are at = least as good as a stack composed of TLS 1.3  using = TCP"

 

HTTP/2 over TLS = 1.3 does not expose these, and so as Jana mentioned, you'd have to = convince the HTTP/2 working group to expose these = first.

 

[Ritesh] There = is no specific sequencing of proposing enhancements mentioned in the = charter or anywhere else. In any case we understand it would be good to = have a precedent =E2=80=93 we are considering making a proposal in the = HTTP/2 WG.

 

 

On Mon, = Jan 9, 2017 at 2:05 PM, Abilash Menon <amenon@128technology.com> = wrote:

Lin,

 

We had suggested priority and streamed as a starting = point to get more network aware details from the application. When you = say signaling - are you indicating signaling to setup the network = elements to start looking for QUIC packets or for something else. Please = clarify.

 

Thanks,

Abilash

 

On Jan 9, 2017, at 3:15 PM, Lin Han <Lin.Han@huawei.com> = wrote:

 

Hi, Abilash

 

I have a question which might be related to this = topic.

 

From the point of view of network device, we want to know and also wish = that the QUIC could support the signaling for the network device along = the path.

This is for the QoS enhancement consideration in the future. Marking = priority is not enough for provisioning a = device.

The lesson from TCP is its rigidity for the extension. It would be nice = that QUIC has such elastic from the beginning of the = design.

 

Thanks

 

Lin

 

From: <= /span>QUIC [mailto:quic-bounces@ietf.org] On = Behalf Of Abilas= h Menon
Sent: Friday, = January 06, 2017 5:17 AM
To: Jana = Iyengar
Cc: Ritesh = Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: = soliciting feedback on = draft-abilash-quic-network

 

Jana,

 

Thank you for reviewing. Please see inline = :

 

On Jan 5, 2017, at 10:52 PM, Jana Iyengar <jri@google.com> = wrote:

 

Hi,

 

Thanks for writing up the draft -- as Patrick notes, = it's helpful to have something concrete to = discuss.

 

I have a number of thoughts as I catch up on this = thread, but I have a high-order one: have you considered proposing this = draft for HTTP/2? Given that the use of streams is basically the same = for HTTP/2 and HTTP over QUIC, I would expect that signaling stream IDs = and priorities for HTTP/2 should be similar. Why not propose it for = HTTP/2?

 

We did not consider that, but we certainly could. = Thank you for the suggestion.

 

=

 

There are a significant number of engineering issues = with doing priorities per stream, the most significant one being the one = that Christian points out: that congestion control and loss detection = will need to be per-stream, defeating a major rationale for stream = multiplexing. That is a show-stopper, in my opinion. You'd have the same = troubles with TCP and = HTTP/2.

 

So if you consider packet pacing with multiple = streams, the latency of one stream need not be affected by another if = one specific stream gets affected. Yes this would need per stream = congestion control - it looks like you done want to have that granular = control here. So is there any network assistance you would like the = protocol to get if the network elements can support it. If so , please = let us know - we would like to = understand. 

 

=

 

I don't think prioritizing streams by network elements = makes good engineering = sense.

 

Prioritization could certainly help streams. That = could use the RFC7657 which Ted had mentioned, but our approach was to = leverage the QUIC protocol itself to use priority and get more granular = view of the network using stream ids. We will see if we can get some = useful results.

 

Thanks,

Abilash

 

 

=

 

- jana

 

 

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Reply = in-line.

 

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <amenon@128technology.com> = wrote:

Hey = Ted,

 

Thanks for your feedback. Please see replies inline = :

 

On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

 

Howdy,

Forgive the top posting, but this seems to be a bit of = meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, = so that on-path devices may move certain streams onto higher priority = paths or otherwise give variable quality of = service.

 

That is one use case yes. The on-path devices can = provide quality of services on a per stream = basis. 

 

=

 

For this to work correctly, though, the basic aim of = multiplexing seems to be changed as you could not multiplex streams into = the same packet, even if they have the same desired network = treatment.  At that level of isolation, independent QUIC = connections may suit your use cases just as well (if, indeed, you would = choose QUIC at all).  If that is the required level of = independence, why does opening different connections not work as = well?

 

Using stream1, the connection gets established and the = headers get exchanged using stream 3. Opening multiple connections would = incur more latency for the connection setup. So with one QUIC = connection, multiple streams can leverage the same connection without = taking the hit of the connection establishment latency for each = stream.

 

With 0RTT, this is probably not an issue for a = long-lived flows, and it has to be compared to the cost for application = mechanics to make sure that each packet contains elements from only a = single stream.  For a multiplexing protocol, the latter seems = fundamentally sub-optimal.

 

 

=


It's also not clear why you need that = level of independence. At the very least, your description makes it seem = that you could multiplex streams whose desired network treatment is the = same.  And, if you did multiplex streams with the same desired = network treatment, there seems to be no need at all to expose the stream = identifiers (after all, you might have more than one stream in a = packet).

 

Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the = draft. The packet pacing mechanism will also benefit from this as it can = be done a per stream basis and not for the whole = connection. 

 

 

So, "building the QUIC state machine in the = network elements" doesn't mean much absent a knowledge of what = those network elements are going to do with the state.  The use = case that you mentioned originally, path selection for network = treatment, doesn't actually require that the on-path elements = distinguish among streams that require like treatment.  It simply = requires that the requested network treatment be visible.  Given = that multiplexing streams that require like network treatment works with = the multiplexed design of QUIC, I'm still unclear why you want to insist = on such a strict independence.

 

  Instead, you would only need to expose the = desired network treatment for a specific packet.  Why is that not = enough to meet the need and why, if that is the case, would = differentiated DSCP markings not meet your = needs?

 

Yes. Network treatment of a packet (priority) is = definitely needed. Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the = draft. The packet pacing mechanism will also benefit from this as it can = be done a per stream basis and not for the whole = connection.

 

Your draft says = this:

   However, session aware routers =
will have a flow per
   stream.  =
Hence the packet rate can be adjusted on a per stream =
basis
   and not for the whole =
connection.

Once = again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular.  A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow.  You = are motivating the change in QUIC in order to achieve that for session = aware routers, but without addressing the loss of other basic QUIC = design features.

 

Also, the stream = priority would be used to send among multiple paths in multi path = case. 

 


 

 

On the latter case, there was good bit of discussion = on how well multiple DSCP markings on a single 5-tuple would work in the = context of WEBRTC; if you have not read RFC 7657, I would suggest doing = so, along with = draft-ietf-tsvwg-rtcweb-qos. 

=

 

DSCP may not always guarantee the quality of service = as it could be remarked by the routers in between. It also depends on = other factors within the router eg: burst,  packet rate etc . So = the application priority can get lost.  Based on the QUIC stream = priority, network elements could remark the DSCP value to take a better = path.

=

 

So, I recommended you = look at the document because it treats the problem of having a single = five(or six)-tuple flow have different markings.  Evidently, your = basic answer is to replace the current flow-state management with a = different view of the flow ("session"), using the stream id as = a demultiplexing signal.  You then wish to have a marking for the = session. 

One of = the design goals of QUIC is that it be deployable on the Internet as it = exists, rather than relying on features which must be introduced into = the network to support it.  This effort seems to run counter to = that design goal as well.

 

We are not proposing = any remarking of the QUIC stream priority, but that it will remain the = same. We can add authentication to make sure the fields are in tact. = Also in DSCP case a single flow will usually be given the same priority. = In this case, the single flow/session can be given different priorities = on a per stream basis.

 

 

Of course, there is a potential silly = state here if the session-state aware network elements do something on = one signal and their non-session-state peers act on a different signal; = at best, you'd have to scrub and re-mark to avoid that.  Given = that, I fail to see why the multiple-markings within a flow approach of = RFC 7657 doesn't work at least as well, at least for the Internet as = currently deployed.

regards,

Ted

 

Thanks,

Abilash

 

 

Though pointing primarily at RTP flows multiplexed = using BUNDLE, I suspect many of the lessons learned would apply to your = efforts, whether you used DSCP or a different = marking.

 

regards,

Ted

 

=

 

On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee = <rmukherjee@128technology.com> = wrote:

Hi = Team,

 

We = recently published draft-abilash-quic-network-00 which proposes a change = to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary: 

 

URL:&nbs= p;           https://www.ietf.org/internet-drafts/draft-abilash= -quic-network-00.txt

Htmlized= :       https://tools.ietf.org/html/draft-abilash-quic-net= work-00

 

Thank = you in advance!

 

Ritesh

 

 

------=_NextPart_000_0153_01D26B1B.4D1D71B0-- From nobody Tue Jan 10 08:44: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 0222212967A for ; Tue, 10 Jan 2017 08:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 pOv68fgaJm3S for ; Tue, 10 Jan 2017 08:44:41 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 3C705129668 for ; Tue, 10 Jan 2017 08:44:41 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id r136so25797231vke.1 for ; Tue, 10 Jan 2017 08:44: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=OyRPb7451+7LcEKgse97uao7GT5tL6fUBTrGR8B4Tjk=; b=Q6N0sTNMSIGcNhw9ycVEWoJ9E7tM2esIiBdam4zMgENRblOIQRxuZhgEXMYtDk0bwR p4CeLZkOzYU9zkE1udY9KcvybMc5QsInEeNhXARVw+OlI1Z1J+qsY+QvmZbwrgcAh3TS swYK6ODTAd8ZxrIn1nxdGnk4Afkhb+xUjUJ6HLN1TWrl5M/Gkw3WudA1X40QFUayJOYP eTs0mRYfo9iJNafFx0WBSA2S1cDEb2JxvWGB/pN4UeMq6J8BiWP1vw50Hcn9fwI/Wjzw gM/KODi8rfS7es1vX4i4Ikd88E4vtIeMy3tPud54Vl9if4NIaDwSvT9EysqrFPcQKm7D iarg== 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=OyRPb7451+7LcEKgse97uao7GT5tL6fUBTrGR8B4Tjk=; b=tYuA1qv2axUemt8trwcKxrFFGTvnl1yRHvslZGfoKlIxZVKPz4YDXoGTsjdy31pT5i cjbh6Sc22Ww4sFDIXpNCCvVOSqEqV/e1HtbLDyew2HBPJ55SW+UZFTV192hXCxteiEtV mjzT2FeD6fBiI9iaq3nBZilyWMorFGasxlJPMzMqgK2+eTIjXBmXYMgoUywnE378WAvD dAAWjWS62KjB1Fk1fPcZWxiAMBD2kb7oluekbu2nklHzFRV738zYNgR0cBNvpLkMlz7g PQOHBtjxjepNkgBK27Wn5vYoZJ58HYKgIHfuqZ0kvcfNuJe2zHDbhRijtvhZIRaE4tSQ LDIA== X-Gm-Message-State: AIkVDXLpxNifGUQBwvcpwbR2v52tWFE8uwDJPS7zc+O5R9m24fWUrzwd2A0uP/aWHRCNQSIUmp7DiE73aALX0Wri X-Received: by 10.31.200.4 with SMTP id y4mr1852955vkf.115.1484066679933; Tue, 10 Jan 2017 08:44:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 10 Jan 2017 08:44:39 -0800 (PST) In-Reply-To: <015201d26b5e$5b3bcfb0$11b36f10$@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> <015201d26b5e$5b3bcfb0$11b36f10$@128technology.com> From: Jana Iyengar Date: Tue, 10 Jan 2017 08:44:39 -0800 Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Ritesh Mukherjee Content-Type: multipart/alternative; boundary=001a114dd5584823710545c03368 Archived-At: Cc: Abilash Menon , Ian Swett , IETF QUIC WG , Ted Hardie , Lin Han X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Jan 2017 16:44:45 -0000 --001a114dd5584823710545c03368 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 8:26 AM, Ritesh Mukherjee < rmukherjee@128technology.com> wrote: > Please see inline=E2=80=A6 > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Tuesday, January 10, 2017 7:33 AM > *To:* Abilash Menon > *Cc:* Lin Han ; Ritesh Mukherjee < > rmukherjee@128technology.com>; Jana Iyengar ; Ted Hardie = < > ted.ietf@gmail.com>; IETF QUIC WG > *Subject:* Re: soliciting feedback on draft-abilash-quic-network > > > > I have many of the same concerns expressed above, but one specific elemen= t > of this proposal would appear to be a clear violation of the charter, whi= ch > is exposing stream ids and priorities. > > > > [Ritesh] The Stream IDs and priorities would still be authenticated. Are > there any specific attacks you are concerned about? > Stream IDs are currently not exposed in HTTP/2 over TLS. Your proposal would effectively expose HTTP/2 stream IDs for QUIC, which, as Ian points out, would violate the stipulation in the charter. I would encourage having this conversation in the httpbis wg first, and then bring it to QUIC. - jana The charter says: "This work will ensure that QUIC has security and > privacy properties that are at least as good as a stack composed of TLS 1= .3 > using TCP" > > > > HTTP/2 over TLS 1.3 does not expose these, and so as Jana mentioned, you'= d > have to convince the HTTP/2 working group to expose these first. > > > > [Ritesh] There is no specific sequencing of proposing enhancements > mentioned in the charter or anywhere else. In any case we understand it > would be good to have a precedent =E2=80=93 we are considering making a p= roposal in > the HTTP/2 WG. > > > > > > On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon > wrote: > > Lin, > > > > We had suggested priority and streamed as a starting point to get more > network aware details from the application. When you say signaling - are > you indicating signaling to setup the network elements to start looking f= or > QUIC packets or for something else. Please clarify. > > > > Thanks, > > Abilash > > > > On Jan 9, 2017, at 3:15 PM, Lin Han wrote: > > > > Hi, Abilash > > > > I have a question which might be related to this topic. > > > > From the point of view of network device, we want to know and also wish > that the QUIC could support the signaling for the network device along th= e > path. > > This is for the QoS enhancement consideration in the future. Marking > priority is not enough for provisioning a device. > > The lesson from TCP is its rigidity for the extension. It would be nice > that QUIC has such elastic from the beginning of the design. > > > > Thanks > > > > Lin > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Abilash Menon > *Sent:* Friday, January 06, 2017 5:17 AM > *To:* Jana Iyengar > *Cc:* Ritesh Mukherjee; Ted Hardie; IETF QUIC WG > *Subject:* Re: soliciting feedback on draft-abilash-quic-network > > > > Jana, > > > > Thank you for reviewing. Please see inline : > > > > On Jan 5, 2017, at 10:52 PM, Jana Iyengar wrote: > > > > Hi, > > > > Thanks for writing up the draft -- as Patrick notes, it's helpful to have > something concrete to discuss. > > > > I have a number of thoughts as I catch up on this thread, but I have a > high-order one: have you considered proposing this draft for HTTP/2? Give= n > that the use of streams is basically the same for HTTP/2 and HTTP over > QUIC, I would expect that signaling stream IDs and priorities for HTTP/2 > should be similar. Why not propose it for HTTP/2? > > > > We did not consider that, but we certainly could. Thank you for the > suggestion. > > > > > > There are a significant number of engineering issues with doing prioritie= s > per stream, the most significant one being the one that Christian points > out: that congestion control and loss detection will need to be per-strea= m, > defeating a major rationale for stream multiplexing. That is a > show-stopper, in my opinion. You'd have the same troubles with TCP and > HTTP/2. > > > > So if you consider packet pacing with multiple streams, the latency of on= e > stream need not be affected by another if one specific stream gets > affected. Yes this would need per stream congestion control - it looks li= ke > you done want to have that granular control here. So is there any network > assistance you would like the protocol to get if the network elements can > support it. If so , please let us know - we would like to understand. > > > > > > I don't think prioritizing streams by network elements makes good > engineering sense. > > > > Prioritization could certainly help streams. That could use the RFC7657 > which Ted had mentioned, but our approach was to leverage the QUIC protoc= ol > itself to use priority and get more granular view of the network using > stream ids. We will see if we can get some useful results. > > > > Thanks, > > Abilash > > > > > > > > - jana > > > > > > On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie wrote: > > Reply in-line. > > > > On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon > wrote: > > Hey Ted, > > > > Thanks for your feedback. Please see replies inline : > > > > On Jan 5, 2017, at 2:57 PM, Ted Hardie wrote: > > > > Howdy, > > Forgive the top posting, but this seems to be a bit of meta-question. If > I read your draft correctly, you are suggesting that QUIC expose stream > identifiers and associate them with a priority, so that on-path devices m= ay > move certain streams onto higher priority paths or otherwise give variabl= e > quality of service. > > > > That is one use case yes. The on-path devices can provide quality of > services on a per stream basis. > > > > > > For this to work correctly, though, the basic aim of multiplexing seems t= o > be changed as you could not multiplex streams into the same packet, even = if > they have the same desired network treatment. At that level of isolation= , > independent QUIC connections may suit your use cases just as well (if, > indeed, you would choose QUIC at all). If that is the required level of > independence, why does opening different connections not work as well? > > > > Using stream1, the connection gets established and the headers get > exchanged using stream 3. Opening multiple connections would incur more > latency for the connection setup. So with one QUIC connection, multiple > streams can leverage the same connection without taking the hit of the > connection establishment latency for each stream. > > > > With 0RTT, this is probably not an issue for a long-lived flows, and it > has to be compared to the cost for application mechanics to make sure tha= t > each packet contains elements from only a single stream. For a > multiplexing protocol, the latter seems fundamentally sub-optimal. > > > > > > > It's also not clear why you need that level of independence. At the very > least, your description makes it seem that you could multiplex streams > whose desired network treatment is the same. And, if you did multiplex > streams with the same desired network treatment, there seems to be no nee= d > at all to expose the stream identifiers (after all, you might have more > than one stream in a packet). > > > > Stream id being exposed would help build QUIC state machine in the networ= k > elements for each stream as mentioned in the draft. The packet pacing > mechanism will also benefit from this as it can be done a per stream basi= s > and not for the whole connection. > > > > > > So, "building the QUIC state machine in the network elements" doesn't mea= n > much absent a knowledge of what those network elements are going to do wi= th > the state. The use case that you mentioned originally, path selection fo= r > network treatment, doesn't actually require that the on-path elements > distinguish among streams that require like treatment. It simply require= s > that the requested network treatment be visible. Given that multiplexing > streams that require like network treatment works with the multiplexed > design of QUIC, I'm still unclear why you want to insist on such a strict > independence. > > > > Instead, you would only need to expose the desired network treatment fo= r > a specific packet. Why is that not enough to meet the need and why, if > that is the case, would differentiated DSCP markings not meet your needs? > > > > Yes. Network treatment of a packet (priority) is definitely needed. Strea= m > id being exposed would help build QUIC state machine in the network > elements for each stream as mentioned in the draft. The packet pacing > mechanism will also benefit from this as it can be done a per stream basi= s > and not for the whole connection. > > > > Your draft says this: > > However, session aware routers will have a flow per > > stream. Hence the packet rate can be adjusted on a per stream basis > > and not for the whole connection. > > Once again, this seems to run counter to the design of a multiplexed > protocol, and the description in the document is a bit circular. A sessi= on > aware router certainly would not have a flow per stream as QUIC is design= ed > now; it would have no way to create such a flow. You are motivating the > change in QUIC in order to achieve that for session aware routers, but > without addressing the loss of other basic QUIC design features. > > > > Also, the stream priority would be used to send among multiple paths in > multi path case. > > > > > > > > > On the latter case, there was good bit of discussion on how well multiple > DSCP markings on a single 5-tuple would work in the context of WEBRTC; if > you have not read RFC 7657, I would suggest doing so, along with > draft-ietf-tsvwg-rtcweb-qos. > > > > DSCP may not always guarantee the quality of service as it could be > remarked by the routers in between. It also depends on other factors with= in > the router eg: burst, packet rate etc . So the application priority can > get lost. Based on the QUIC stream priority, network elements could rema= rk > the DSCP value to take a better path. > > > > So, I recommended you look at the document because it treats the problem > of having a single five(or six)-tuple flow have different markings. > Evidently, your basic answer is to replace the current flow-state > management with a different view of the flow ("session"), using the strea= m > id as a demultiplexing signal. You then wish to have a marking for the > session. > > One of the design goals of QUIC is that it be deployable on the Internet > as it exists, rather than relying on features which must be introduced in= to > the network to support it. This effort seems to run counter to that desi= gn > goal as well. > > > > We are not proposing any remarking of the QUIC stream priority, but that > it will remain the same. We can add authentication to make sure the field= s > are in tact. Also in DSCP case a single flow will usually be given the sa= me > priority. In this case, the single flow/session can be given different > priorities on a per stream basis. > > > > > > Of course, there is a potential silly state here if the session-state > aware network elements do something on one signal and their > non-session-state peers act on a different signal; at best, you'd have to > scrub and re-mark to avoid that. Given that, I fail to see why the > multiple-markings within a flow approach of RFC 7657 doesn't work at leas= t > as well, at least for the Internet as currently deployed. > > regards, > > Ted > > > > Thanks, > > Abilash > > > > > > Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspec= t > many of the lessons learned would apply to your efforts, whether you used > DSCP or a different marking. > > > > regards, > > Ted > > > > > > On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < > rmukherjee@128technology.com> wrote: > > Hi Team, > > > > We recently published draft-abilash-quic-network-00 which proposes a > change to the QUIC protocol header that will allow network elements to > prioritize streams in QUIC packets, divert high priority streams to low > loss paths, and adjust packet pacing on a per stream basis. We have alrea= dy > received some very positive comments from some members but wanted to > solicit feedback from the larger community. Please provide your > comments/feedback/recommendations as necessary: > > > > URL: https://www.ietf.org/internet-drafts/ > draft-abilash-quic-network-00.txt > > Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 > > > > Thank you in advance! > > > > Ritesh > > > > > --001a114dd5584823710545c03368 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 8:26 AM, Ritesh Mukherjee <= ;rmukherj= ee@128technology.com> wrote:

Please see inline=E2=80=A6<= u>

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent:= Tuesday, January 10, 2017 7:33 AM
To: Abilash Menon <amenon@128technol= ogy.com>
Cc: Lin Han <Lin.Han@huawei.com>; Ritesh Mukherjee <rmukherjee@1= 28technology.com>; Jana Iyengar <jri@google.com>; Ted Hardie <ted.ietf@gmail.com>; IE= TF QUIC WG <quic@ietf= .org>
Subject: Re: soliciting feedback on= draft-abilash-quic-network

=C2=A0

I have many= of the same concerns expressed above, but one specific element of this pro= posal would appear to be a clear violation of the charter, which is exposin= g stream ids and priorities.

=C2=A0

[Ritesh] The Stream IDs = and priorities would still be authenticated. Are there any specific attacks= you are concerned about?


Stream IDs are currently not exposed in HTTP/2 over TLS. = Your proposal would effectively expose HTTP/2 stream IDs for QUIC, which, a= s Ian points out, would violate the stipulation in the charter. I would enc= ourage having this conversation in the httpbis wg first, and then bring it = to QUIC.

- jana

The charter says: "Th= is work will ensure that QUIC has security and privacy=C2=A0properties that= are at least as good as a stack composed of TLS 1.3 =C2=A0using TCP"<= u>

=C2=A0

HTTP/2 over TLS 1.3 does not expose these, a= nd so as Jana mentioned, you'd have to convince the HTTP/2 working grou= p to expose these first.

=C2=A0

[Ritesh] There = is no specific sequencing of proposing enhancements mentioned in the charte= r or anywhere else. In any case we understand it would be good to have a pr= ecedent =E2=80=93 we are considering making a proposal in the HTTP/2 WG.

= =C2=A0

=C2=A0

On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon= <amenon@1= 28technology.com> wrote:

Lin,

=C2=A0

We had suggested priority and streamed as a starting point to g= et more network aware details from the application. When you say signaling = - are you indicating signaling to setup the network elements to start looki= ng for QUIC packets or for something else. Please clarify.

=C2=A0

Thanks,

Abilash

<= /u>=C2=A0

On Jan 9, 2017, at 3:15 PM, Lin Han &l= t;Lin.Han@huawei.co= m> wrote:

=C2= =A0

Hi, Abil= ash

=C2=A0

I have a question which might be related to this topic.<= /u>

=C2=A0

From th= e point of view of network device, we want to know and also wish that the Q= UIC could support the signaling for the network device along the path.

This i= s for the QoS enhancement consideration in the future. Marking priority is = not enough for provisioning a device.

The lesson from TCP is its rigidity for= the extension. It would be nice that QUIC has such elastic from the beginn= ing of the design.

=C2=A0

Thanks

=C2=A0

Lin

=C2=A0

From:=C2=A0QUIC [mailt= o:quic-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Abilash Menon
Sent:=C2=A0Friday, January 06, 2= 017 5:17 AM
To:=C2=A0Jana Iyengar
Cc:=C2= =A0Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject:= =C2=A0Re: soliciting feedback on draft-abilash-quic-network

=C2=A0=

Jana,

<= div>

=C2=A0

Thank you for reviewing. Please see inline :

=C2=A0<= /u>

On Jan 5, 2017, at 10:52 PM, Jana Iyenga= r <jri@google.com> wrote:

=C2=A0

Hi,

=C2=A0

Thanks for writing up the draft -- as Patrick notes, it's helpful to= have something concrete to discuss.

=C2=A0

I have a number of thoughts as I catch up on this thread,= but I have a high-order one: have you considered proposing this draft for = HTTP/2? Given that the use of streams is basically the same for HTTP/2 and = HTTP over QUIC, I would expect that signaling stream IDs and priorities for= HTTP/2 should be similar. Why not propose it for HTTP/2?

=

=C2= =A0

We did no= t consider that, but we certainly could. Thank you for the suggestion.

=C2=A0

=C2=A0

There are a significant number of engineering issues with doing priorities= per stream, the most significant one being the one that Christian points o= ut: that congestion control and loss detection will need to be per-stream, = defeating a major rationale for stream multiplexing. That is a show-stopper= , in my opinion. You'd have the same troubles with TCP and HTTP/2.

=C2= =A0

So if you= consider packet pacing with multiple streams, the latency of one stream ne= ed not be affected by another if one specific stream gets affected. Yes thi= s would need per stream congestion control - it looks like you done want to= have that granular control here. So is there any network assistance you wo= uld like the protocol to get if the network elements can support it. If so = , please let us know - we would like to understand.=C2=A0

=

<= /u>=C2=A0

=C2=A0=

I don't = think prioritizing streams by network elements makes good engineering sense= .

=C2=A0

Prior= itization could certainly help streams. That could use the RFC7657 which Te= d had mentioned, but our approach was to leverage the QUIC protocol itself = to use priority and get more granular view of the network using stream ids.= We will see if we can get some useful results.

=C2=A0

Thanks,

Abilash

=C2=A0

=C2=A0

<= div>

=C2=A0

- jana

=C2=A0

=C2=A0

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <ted= .ietf@gmail.com> wrote:

Reply in-line.

=C2=A0

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <amenon= @128technology.com> wrote:

<= p class=3D"MsoNormal">Hey Ted,

=C2=A0

Thanks for your feedback. Please see replies inline :

=C2=A0

On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

=C2=A0

Howdy,

Forgive the top posting, but thi= s seems to be a bit of meta-question.=C2=A0 If I read your draft correctly,= you are suggesting that QUIC expose stream identifiers and associate them = with a priority, so that on-path devices may move certain streams onto high= er priority paths or otherwise give variable quality of service.<= /u>

=C2=A0

That is one use case yes. The on-path devices can provide quality of serv= ices on a per stream basis.=C2=A0

=C2=A0

=C2=A0

<= /div>

For this to work correctly, though, = the basic aim of multiplexing seems to be changed as you could not multiple= x streams into the same packet, even if they have the same desired network = treatment.=C2=A0 At that level of isolation, independent QUIC connections m= ay suit your use cases just as well (if, indeed, you would choose QUIC at a= ll).=C2=A0 If that is the required level of independence, why does opening = different connections not work as well?

=

=C2=A0

=

Using stream1, the connection gets establi= shed and the headers get exchanged using stream 3. Opening multiple connect= ions would incur more latency for the connection setup. So with one QUIC co= nnection, multiple streams can leverage the same connection without taking = the hit of the connection establishment latency for each stream.<= /u>

=C2= =A0

With 0RTT= , this is probably not an issue for a long-lived flows, and it has to be co= mpared to the cost for application mechanics to make sure that each packet = contains elements from only a single stream.=C2=A0 For a multiplexing proto= col, the latter seems fundamentally sub-optimal.

=C2=A0

=C2=A0


It's also not clear why you need that level of independence= . At the very least, your description makes it seem that you could multiple= x streams whose desired network treatment is the same.=C2=A0 And, if you di= d multiplex streams with the same desired network treatment, there seems to= be no need at all to expose the stream identifiers (after all, you might h= ave more than one stream in a packet).

<= /div>

=C2=A0

<= div>

Stream id being exposed would help build QUIC st= ate machine in the network elements for each stream as mentioned in the dra= ft. The packet pacing mechanism will also benefit from this as it can be do= ne a per stream basis and not for the whole connection.=C2=A0=

=C2=A0

=C2=A0<= u>

So, "bui= lding the QUIC state machine in the network elements" doesn't mean= much absent a knowledge of what those network elements are going to do wit= h the state.=C2=A0 The use case that you mentioned originally, path selecti= on for network treatment, doesn't actually require that the on-path ele= ments distinguish among streams that require like treatment.=C2=A0 It simpl= y requires that the requested network treatment be visible.=C2=A0 Given tha= t multiplexing streams that require like network treatment works with the m= ultiplexed design of QUIC, I'm still unclear why you want to insist on = such a strict independence.

=C2=A0

=
<= div>

=C2=A0 Instead, you would only need to expo= se the desired network treatment for a specific packet.=C2=A0 Why is that n= ot enough to meet the need and why, if that is the case, would differentiat= ed DSCP markings not meet your needs?

=C2=A0

<= /div>

Yes. Network treatment of a pac= ket (priority) is definitely needed. Stream id being exposed would help bui= ld QUIC state machine in the network elements for each stream as mentioned = in the draft. The packet pacing mechanism will also benefit from this as it= can be done a per stream basis and not for the whole connection.=

=C2=A0

Your draft says this:

=
=C2=A0=C2=A0 However, session aware routers will have a flow per<=
/u>
=C2=A0=C2=A0 stream.=C2=A0 Hence the packet rate can be adjus=
ted on a per stream basis
=C2=A0=C2=A0 and not for =
the whole connection.

Once again, this seems to run counter to the design of a multiplexed p= rotocol, and the description in the document is a bit circular.=C2=A0 A ses= sion aware router certainly would not have a flow per stream as QUIC is des= igned now; it would have no way to create such a flow.=C2=A0 You are motiva= ting the change in QUIC in order to achieve that for session aware routers,= but without addressing the loss of other basic QUIC design features.

=C2=A0

Also, the stream priority would be used to send among multiple paths i= n multi path case.=C2=A0

=C2=A0


=C2=A0

=C2=A0

On the latter case, there was good= bit of discussion on how well multiple DSCP markings on a single 5-tuple w= ould work in the context of WEBRTC; if you have not read RFC 7657, I would = suggest doing so, along with draft-ietf-tsvwg-rtcweb-qos.=C2=A0

=C2=A0

DSCP = may not always guarantee the quality of service as it could be remarked by = the routers in between. It also depends on other factors within the router = eg: burst, =C2=A0packet rate etc . So the application priority can get lost= .=C2=A0 Based on the QUIC stream priority, network elements could remark th= e DSCP value to take a better path.

=C2=A0<= /p>

S= o, I recommended you look at the document because it treats the problem of = having a single five(or six)-tuple flow have different markings.=C2=A0 Evid= ently, your basic answer is to replace the current flow-state management wi= th a different view of the flow ("session"), using the stream id = as a demultiplexing signal.=C2=A0 You then wish to have a marking for the s= ession.=C2=A0

One o= f the design goals of QUIC is that it be deployable on the Internet as it e= xists, rather than relying on features which must be introduced into the ne= twork to support it.=C2=A0 This effort seems to run counter to that design = goal as well.

=C2=A0

We are not proposing any remarking of the QUIC stre= am priority, but that it will remain the same. We can add authentication to= make sure the fields are in tact. Also in DSCP case a single flow will usu= ally be given the same priority. In this case, the single flow/session can = be given different priorities on a per stream basis.

=C2=A0

=C2=A0<= /u>

Of course, there is a potential silly state here if the session-state = aware network elements do something on one signal and their non-session-sta= te peers act on a different signal; at best, you'd have to scrub and re= -mark to avoid that.=C2=A0 Given that, I fail to see why the multiple-marki= ngs within a flow approach of RFC 7657 doesn't work at least as well, a= t least for the Internet as currently deployed.

regards,

Ted

=C2=A0

Thanks,<= /u>

Abilash

=C2=A0<= /p>

=C2=A0

Though pointing primarily at RTP flows = multiplexed using BUNDLE, I suspect many of the lessons learned would apply= to your efforts, whether you used DSCP or a different marking.

=C2= =A0

regards,

Ted

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee <= rmukherjee@128technology.com> wrote:

Hi Team,

=C2=A0

We recently pub= lished draft-abilash-quic-network-00 which proposes a change to the QUIC pr= otocol header that will allow network elements to prioritize streams in QUI= C packets, divert high priority streams to low loss paths, and adjust packe= t pacing on a per stream basis. We have already received some very positive= comments from some members but wanted to solicit feedback from the larger = community. Please provide your comments/feedback/recommendations as ne= cessary:=C2=A0

=C2=A0=

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-abil= ash-quic-network-00.txt

Htmlize= d:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-abilash-qu= ic-network-00

=C2=A0=

Thank you in advance!

=C2=A0

Ritesh

=

=C2=A0

=C2=A0

<= /div>
--001a114dd5584823710545c03368-- From nobody Tue Jan 10 09:00: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 B0C98129D3A for ; Tue, 10 Jan 2017 09:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 aq9j5OypjSx3 for ; Tue, 10 Jan 2017 09:00:52 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FB8129624 for ; Tue, 10 Jan 2017 09:00:52 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 189so37529141pfu.3 for ; Tue, 10 Jan 2017 09:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=RBPIyHmsyfSeKeXAqoYdct6durmRxMTpL6pDW41xxok=; b=yUfbW/JA1Xe3hVC6+HgasDACQoG6AqTzti0t4e7SKPK6x2P42p8QwjlxYaPrD1/YU7 zaWID9rMWDyxqZMxFvmotB/r0cwnP/AYKSjVNyY14RLIvJ7JfwFtz5eT7hoPogh50B6o lmYBxhKShy6bXSXxzpx8v29IEt0q7XftL6e+7y4S9XfsUxMyPHbLNRQ38YWnwHRb9jNt ujax9zgDTTik83Cix4OWxidxabLrfwf2c0dN+g8HHN9iUsBCatgTzhIVPL1iy7X/E7rA H7v46SvkjSc9xFQV+epNjADVJdLV8BlzxqGcOiDTyN6dYmnH9fmE3s5Z82wgdAqz1VYM GhDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=RBPIyHmsyfSeKeXAqoYdct6durmRxMTpL6pDW41xxok=; b=WWAlQiWa+NSCOFSsb3zBLCyBABBhz07kVriFiG8Bf4wsFHirfhpZemq8HnuGPhp1SS iWJSOMYDKQvMkVsPOEEEgxLmEIf8l8anCXATcLqe42pjnhh4hAUacsENaFExI75OCmgi y0A7aXZqYbetSDVwpoTTm0v6dyv7QA9V+t/FOW2pGpEVJ0YIaFEs5XVImD1J79G+JFQe Yl8afUjrqsDEsl/W7bV6OCggAnEEIgazfFTjbcW8hTpp+GlCn8dVgbhlotZSt9B/QdOS WwD1tIjTMiSlvPHDC3Hng0gTUxCllHcHeGdG4pK5prmPtDO6XnoUkeSVOxsZ0dNopz1M zVXQ== X-Gm-Message-State: AIkVDXLBsqcuC844OkvNPWbgukcOVcpdiCKnJn/DEONVpIfPgd8MhYBFAeTvQk2isqj3Myd1 X-Received: by 10.98.47.68 with SMTP id v65mr4907403pfv.115.1484067651444; Tue, 10 Jan 2017 09:00:51 -0800 (PST) Received: from DESKTOP8OQ9GIB ([69.162.16.14]) by smtp.gmail.com with ESMTPSA id d69sm7113917pfd.11.2017.01.10.09.00.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 09:00:50 -0800 (PST) From: "Ritesh Mukherjee" To: "'Jana Iyengar'" References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> <015201d26b5e$5b3bcfb0$11b36f10$@128technology.com> In-Reply-To: Subject: RE: soliciting feedback on draft-abilash-quic-network Date: Tue, 10 Jan 2017 09:00:48 -0800 Message-ID: <01a501d26b63$17bde160$4739a420$@128technology.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A6_01D26B20.09A6FD70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHdW5MPCBQI3E7Yzcbczzhdf2tIqgGvJEeDAppKLl0Dqrj3LwGgee/KAb92KYABzqp1ywJ07BAbAf76tEABrzOqrQG3Hts5oHQlzDA= Content-Language: en-us Archived-At: Cc: 'Abilash Menon' , 'Ian Swett' , 'IETF QUIC WG' , 'Ted Hardie' , 'Lin Han' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Jan 2017 17:00:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A6_01D26B20.09A6FD70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Jana Iyengar [mailto:jri@google.com]=20 Sent: Tuesday, January 10, 2017 8:45 AM To: Ritesh Mukherjee Cc: Ian Swett ; Abilash Menon = ; Lin Han ; Ted Hardie = ; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network =20 =20 =20 On Tue, Jan 10, 2017 at 8:26 AM, Ritesh Mukherjee = > = wrote: Please see inline=E2=80=A6 =20 From: Ian Swett [mailto:ianswett@google.com = ]=20 Sent: Tuesday, January 10, 2017 7:33 AM To: Abilash Menon > Cc: Lin Han >; Ritesh = Mukherjee >; Jana Iyengar >; Ted Hardie >; IETF QUIC WG > Subject: Re: soliciting feedback on draft-abilash-quic-network =20 I have many of the same concerns expressed above, but one specific = element of this proposal would appear to be a clear violation of the = charter, which is exposing stream ids and priorities. =20 [Ritesh] The Stream IDs and priorities would still be authenticated. Are = there any specific attacks you are concerned about? =20 Stream IDs are currently not exposed in HTTP/2 over TLS. Your proposal = would effectively expose HTTP/2 stream IDs for QUIC, which, as Ian = points out, would violate the stipulation in the charter. I would = encourage having this conversation in the httpbis wg first, and then = bring it to QUIC. =20 - jana =20 =20 [Ritesh] We understand. The charter mentions it needs to be =E2=80=9Cas = good as=E2=80=9D HTTP/2 over TLS and we can propose it there too. = However I was hoping for why this would make it less secure rather than = if httpbis did it then we will too. Anyway=E2=80=A6 =20 The charter says: "This work will ensure that QUIC has security and = privacy properties that are at least as good as a stack composed of TLS = 1.3 using TCP" =20 HTTP/2 over TLS 1.3 does not expose these, and so as Jana mentioned, = you'd have to convince the HTTP/2 working group to expose these first. =20 [Ritesh] There is no specific sequencing of proposing enhancements = mentioned in the charter or anywhere else. In any case we understand it = would be good to have a precedent =E2=80=93 we are considering making a = proposal in the HTTP/2 WG.=20 =20 =20 On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon > wrote: Lin, =20 We had suggested priority and streamed as a starting point to get more = network aware details from the application. When you say signaling - are = you indicating signaling to setup the network elements to start looking = for QUIC packets or for something else. Please clarify. =20 Thanks, Abilash =20 On Jan 9, 2017, at 3:15 PM, Lin Han > wrote: =20 Hi, Abilash =20 I have a question which might be related to this topic. =20 >From the point of view of network device, we want to know and also wish = that the QUIC could support the signaling for the network device along = the path. This is for the QoS enhancement consideration in the future. Marking = priority is not enough for provisioning a device. The lesson from TCP is its rigidity for the extension. It would be nice = that QUIC has such elastic from the beginning of the design. =20 Thanks =20 Lin =20 From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Abilash Menon Sent: Friday, January 06, 2017 5:17 AM To: Jana Iyengar Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network =20 Jana, =20 Thank you for reviewing. Please see inline : =20 On Jan 5, 2017, at 10:52 PM, Jana Iyengar < = jri@google.com> wrote: =20 Hi, =20 Thanks for writing up the draft -- as Patrick notes, it's helpful to = have something concrete to discuss. =20 I have a number of thoughts as I catch up on this thread, but I have a = high-order one: have you considered proposing this draft for HTTP/2? = Given that the use of streams is basically the same for HTTP/2 and HTTP = over QUIC, I would expect that signaling stream IDs and priorities for = HTTP/2 should be similar. Why not propose it for HTTP/2? =20 We did not consider that, but we certainly could. Thank you for the = suggestion. =20 =20 There are a significant number of engineering issues with doing = priorities per stream, the most significant one being the one that = Christian points out: that congestion control and loss detection will = need to be per-stream, defeating a major rationale for stream = multiplexing. That is a show-stopper, in my opinion. You'd have the same = troubles with TCP and HTTP/2. =20 So if you consider packet pacing with multiple streams, the latency of = one stream need not be affected by another if one specific stream gets = affected. Yes this would need per stream congestion control - it looks = like you done want to have that granular control here. So is there any = network assistance you would like the protocol to get if the network = elements can support it. If so , please let us know - we would like to = understand.=20 =20 =20 I don't think prioritizing streams by network elements makes good = engineering sense. =20 Prioritization could certainly help streams. That could use the RFC7657 = which Ted had mentioned, but our approach was to leverage the QUIC = protocol itself to use priority and get more granular view of the = network using stream ids. We will see if we can get some useful results. =20 Thanks, Abilash =20 =20 =20 - jana =20 =20 On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie < = ted.ietf@gmail.com> wrote: Reply in-line. =20 On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon < = amenon@128technology.com> wrote: Hey Ted, =20 Thanks for your feedback. Please see replies inline : =20 On Jan 5, 2017, at 2:57 PM, Ted Hardie < = ted.ietf@gmail.com> wrote: =20 Howdy, Forgive the top posting, but this seems to be a bit of meta-question. = If I read your draft correctly, you are suggesting that QUIC expose = stream identifiers and associate them with a priority, so that on-path = devices may move certain streams onto higher priority paths or otherwise = give variable quality of service. =20 That is one use case yes. The on-path devices can provide quality of = services on a per stream basis.=20 =20 =20 For this to work correctly, though, the basic aim of multiplexing seems = to be changed as you could not multiplex streams into the same packet, = even if they have the same desired network treatment. At that level of = isolation, independent QUIC connections may suit your use cases just as = well (if, indeed, you would choose QUIC at all). If that is the = required level of independence, why does opening different connections = not work as well? =20 Using stream1, the connection gets established and the headers get = exchanged using stream 3. Opening multiple connections would incur more = latency for the connection setup. So with one QUIC connection, multiple = streams can leverage the same connection without taking the hit of the = connection establishment latency for each stream. =20 With 0RTT, this is probably not an issue for a long-lived flows, and it = has to be compared to the cost for application mechanics to make sure = that each packet contains elements from only a single stream. For a = multiplexing protocol, the latter seems fundamentally sub-optimal. =20 =20 It's also not clear why you need that level of independence. At the very = least, your description makes it seem that you could multiplex streams = whose desired network treatment is the same. And, if you did multiplex = streams with the same desired network treatment, there seems to be no = need at all to expose the stream identifiers (after all, you might have = more than one stream in a packet). =20 Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection.=20 =20 =20 So, "building the QUIC state machine in the network elements" doesn't = mean much absent a knowledge of what those network elements are going to = do with the state. The use case that you mentioned originally, path = selection for network treatment, doesn't actually require that the = on-path elements distinguish among streams that require like treatment. = It simply requires that the requested network treatment be visible. = Given that multiplexing streams that require like network treatment = works with the multiplexed design of QUIC, I'm still unclear why you = want to insist on such a strict independence. =20 Instead, you would only need to expose the desired network treatment = for a specific packet. Why is that not enough to meet the need and why, = if that is the case, would differentiated DSCP markings not meet your = needs? =20 Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection. =20 Your draft says this: However, session aware routers will have a flow per stream. Hence the packet rate can be adjusted on a per stream basis and not for the whole connection. Once again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular. A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow. You are = motivating the change in QUIC in order to achieve that for session aware = routers, but without addressing the loss of other basic QUIC design = features. =20 Also, the stream priority would be used to send among multiple paths in = multi path case.=20 =20 =20 =20 On the latter case, there was good bit of discussion on how well = multiple DSCP markings on a single 5-tuple would work in the context of = WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=20 =20 DSCP may not always guarantee the quality of service as it could be = remarked by the routers in between. It also depends on other factors = within the router eg: burst, packet rate etc . So the application = priority can get lost. Based on the QUIC stream priority, network = elements could remark the DSCP value to take a better path. =20 So, I recommended you look at the document because it treats the problem = of having a single five(or six)-tuple flow have different markings. = Evidently, your basic answer is to replace the current flow-state = management with a different view of the flow ("session"), using the = stream id as a demultiplexing signal. You then wish to have a marking = for the session.=20 One of the design goals of QUIC is that it be deployable on the Internet = as it exists, rather than relying on features which must be introduced = into the network to support it. This effort seems to run counter to = that design goal as well. =20 We are not proposing any remarking of the QUIC stream priority, but that = it will remain the same. We can add authentication to make sure the = fields are in tact. Also in DSCP case a single flow will usually be = given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis. =20 =20 Of course, there is a potential silly state here if the session-state = aware network elements do something on one signal and their = non-session-state peers act on a different signal; at best, you'd have = to scrub and re-mark to avoid that. Given that, I fail to see why the = multiple-markings within a flow approach of RFC 7657 doesn't work at = least as well, at least for the Internet as currently deployed. regards, Ted =20 Thanks, Abilash =20 =20 Though pointing primarily at RTP flows multiplexed using BUNDLE, I = suspect many of the lessons learned would apply to your efforts, whether = you used DSCP or a different marking. =20 regards, Ted =20 =20 On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < = rmukherjee@128technology.com> = wrote: Hi Team, =20 We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary:=20 =20 URL: = = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt Htmlized: = = https://tools.ietf.org/html/draft-abilash-quic-network-00 =20 Thank you in advance! =20 Ritesh =20 =20 =20 ------=_NextPart_000_01A6_01D26B20.09A6FD70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Jana Iyengar [mailto:jri@google.com]
Sent: Tuesday, January = 10, 2017 8:45 AM
To: Ritesh Mukherjee = <rmukherjee@128technology.com>
Cc: Ian Swett = <ianswett@google.com>; Abilash Menon = <amenon@128technology.com>; Lin Han <Lin.Han@huawei.com>; = Ted Hardie <ted.ietf@gmail.com>; IETF QUIC WG = <quic@ietf.org>
Subject: Re: soliciting feedback on = draft-abilash-quic-network

 

 

 

On Tue, = Jan 10, 2017 at 8:26 AM, Ritesh Mukherjee <rmukherjee@128technology.com> = wrote:

Please see = inline=E2=80=A6

 

From:<= /b> = Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, = January 10, 2017 7:33 AM
To: Abilash Menon <amenon@128technology.com>
Cc: Lin Han = <Lin.Han@huawei.com>; Ritesh Mukherjee <rmukherjee@128technology.com>; Jana Iyengar = <jri@google.com>; Ted Hardie <ted.ietf@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: = soliciting feedback on = draft-abilash-quic-network

 <= /o:p>

I have many = of the same concerns expressed above, but one specific element of this = proposal would appear to be a clear violation of the charter, which is = exposing stream ids and priorities.

 <= /o:p>

[Ritesh] The = Stream IDs and priorities would still be authenticated. Are there any = specific attacks you are concerned = about?

 

Stream IDs are currently not exposed in HTTP/2 over = TLS. Your proposal would effectively expose HTTP/2 stream IDs for QUIC, = which, as Ian points out, would violate the stipulation in the charter. = I would encourage having this conversation in the httpbis wg first, and = then bring it to QUIC.

 

- = jana

 

 

[Ritesh] We = understand. The charter mentions it needs to be =E2=80=9Cas good = as=E2=80=9D HTTP/2 over TLS and we can propose it there too. However I = was hoping for why this would make it less secure rather than if httpbis = did it then we will too. = Anyway=E2=80=A6

 

The charter = says: "This work will ensure that = QUIC has security and privacy properties that are at least as good = as a stack composed of TLS 1.3  using = TCP"

 

HTTP/2 over = TLS 1.3 does not expose these, and so as Jana mentioned, you'd have to = convince the HTTP/2 working group to expose these = first.

 

[Ritesh] There = is no specific sequencing of proposing enhancements mentioned in the = charter or anywhere else. In any case we understand it would be good to = have a precedent =E2=80=93 we are considering making a proposal in the = HTTP/2 WG.

 

 

On Mon, Jan = 9, 2017 at 2:05 PM, Abilash Menon <amenon@128technology.com> = wrote:

Lin,

 <= /o:p>

We had = suggested priority and streamed as a starting point to get more network = aware details from the application. When you say signaling - are you = indicating signaling to setup the network elements to start looking for = QUIC packets or for something else. Please = clarify.

 <= /o:p>

Thanks,=

Abilash=

 <= /o:p>

On Jan 9, = 2017, at 3:15 PM, Lin Han <Lin.Han@huawei.com> = wrote:

 <= /o:p>

Hi, Abilash

 

I have a question which might be related to this = topic.

 

From the point of view of network device, we want to know and also wish = that the QUIC could support the signaling for the network device along = the path.

This is for the QoS enhancement consideration in the future. Marking = priority is not enough for provisioning a = device.

The lesson from TCP is its rigidity for the extension. It would be nice = that QUIC has such elastic from the beginning of the = design.

 

Thanks

 

Lin

 

From: <= /span>QUIC [mailto:quic-bounces@ietf.org]&nbs= p;On Behalf Of&nbs= p;Abilash Menon
Sent:&nbs= p;Friday, January 06, 2017 5:17 AM
To:&nbs= p;Jana Iyengar
Cc:&nbs= p;Ritesh Mukherjee; Ted Hardie; IETF QUIC = WG
Subject:&nbs= p;Re: soliciting feedback on = draft-abilash-quic-network

 <= /o:p>

Jana,

 <= /o:p>

Thank you = for reviewing. Please see inline = :

 <= /o:p>

On Jan 5, = 2017, at 10:52 PM, Jana Iyengar <jri@google.com> = wrote:

 <= /o:p>

Hi,

 <= /o:p>

Thanks for = writing up the draft -- as Patrick notes, it's helpful to have something = concrete to discuss.

 <= /o:p>

I have a = number of thoughts as I catch up on this thread, but I have a high-order = one: have you considered proposing this draft for HTTP/2? Given that the = use of streams is basically the same for HTTP/2 and HTTP over QUIC, I = would expect that signaling stream IDs and priorities for HTTP/2 should = be similar. Why not propose it for = HTTP/2?

 <= /o:p>

We did not = consider that, but we certainly could. Thank you for the = suggestion.

 <= /p>

 <= /o:p>

There are a = significant number of engineering issues with doing priorities per = stream, the most significant one being the one that Christian points = out: that congestion control and loss detection will need to be = per-stream, defeating a major rationale for stream multiplexing. That is = a show-stopper, in my opinion. You'd have the same troubles with TCP and = HTTP/2.

 <= /o:p>

So if you = consider packet pacing with multiple streams, the latency of one stream = need not be affected by another if one specific stream gets affected. = Yes this would need per stream congestion control - it looks like you = done want to have that granular control here. So is there any network = assistance you would like the protocol to get if the network elements = can support it. If so , please let us know - we would like to = understand. 

 <= /p>

 <= /o:p>

I don't = think prioritizing streams by network elements makes good engineering = sense.

 <= /o:p>

Prioritizati= on could certainly help streams. That could use the RFC7657 which Ted = had mentioned, but our approach was to leverage the QUIC protocol itself = to use priority and get more granular view of the network using stream = ids. We will see if we can get some useful = results.

 <= /o:p>

Thanks,=

Abilash=

 <= /o:p>

 <= /p>

 <= /o:p>

- = jana

 <= /o:p>

 <= /o:p>

On Thu, Jan = 5, 2017 at 4:08 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Reply = in-line.

 <= /o:p>

On Thu, Jan = 5, 2017 at 3:38 PM, Abilash Menon <amenon@128technology.com> = wrote:

Hey = Ted,

 <= /o:p>

Thanks for = your feedback. Please see replies inline = :

 <= /o:p>

On Jan 5, = 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

 <= /o:p>

Howdy,<= /p>

Forgive the = top posting, but this seems to be a bit of meta-question.  If I = read your draft correctly, you are suggesting that QUIC expose stream = identifiers and associate them with a priority, so that on-path devices = may move certain streams onto higher priority paths or otherwise give = variable quality of = service.

 <= /o:p>

That is one = use case yes. The on-path devices can provide quality of services on a = per stream basis. 

 <= /p>

 <= /o:p>

For this to = work correctly, though, the basic aim of multiplexing seems to be = changed as you could not multiplex streams into the same packet, even if = they have the same desired network treatment.  At that level of = isolation, independent QUIC connections may suit your use cases just as = well (if, indeed, you would choose QUIC at all).  If that is the = required level of independence, why does opening different connections = not work as well?

 <= /o:p>

Using = stream1, the connection gets established and the headers get exchanged = using stream 3. Opening multiple connections would incur more latency = for the connection setup. So with one QUIC connection, multiple streams = can leverage the same connection without taking the hit of the = connection establishment latency for each = stream.

 <= /o:p>

With 0RTT, = this is probably not an issue for a long-lived flows, and it has to be = compared to the cost for application mechanics to make sure that each = packet contains elements from only a single stream.  For a = multiplexing protocol, the latter seems fundamentally = sub-optimal.

 <= /o:p>

 <= /p>


It's = also not clear why you need that level of independence. At the very = least, your description makes it seem that you could multiplex streams = whose desired network treatment is the same.  And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a = packet).

 <= /o:p>

Stream id = being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing = mechanism will also benefit from this as it can be done a per stream = basis and not for the whole = connection. 

 <= /o:p>

 <= /o:p>

So, = "building the QUIC state machine in the network elements" = doesn't mean much absent a knowledge of what those network elements are = going to do with the state.  The use case that you mentioned = originally, path selection for network treatment, doesn't actually = require that the on-path elements distinguish among streams that require = like treatment.  It simply requires that the requested network = treatment be visible.  Given that multiplexing streams that require = like network treatment works with the multiplexed design of QUIC, I'm = still unclear why you want to insist on such a strict = independence.

 <= /o:p>

  = Instead, you would only need to expose the desired network treatment for = a specific packet.  Why is that not enough to meet the need and = why, if that is the case, would differentiated DSCP markings not meet = your = needs?

 <= /o:p>

Yes. = Network treatment of a packet (priority) is definitely needed. Stream id = being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing = mechanism will also benefit from this as it can be done a per stream = basis and not for the whole = connection.

 <= /o:p>

Your draft says = this:

   However, session aware routers =
will have a flow per
   stream.  =
Hence the packet rate can be adjusted on a per stream =
basis
   and not for the whole =
connection.

Once again, = this seems to run counter to the design of a multiplexed protocol, and = the description in the document is a bit circular.  A session aware = router certainly would not have a flow per stream as QUIC is designed = now; it would have no way to create such a flow.  You are = motivating the change in QUIC in order to achieve that for session aware = routers, but without addressing the loss of other basic QUIC design = features.

 <= /o:p>

Also, the = stream priority would be used to send among multiple paths in multi path = case. 

 <= /o:p>


 

 <= /o:p>

On the = latter case, there was good bit of discussion on how well multiple DSCP = markings on a single 5-tuple would work in the context of WEBRTC; if you = have not read RFC 7657, I would suggest doing so, along with = draft-ietf-tsvwg-rtcweb-qos. 

=

 <= /o:p>

DSCP may = not always guarantee the quality of service as it could be remarked by = the routers in between. It also depends on other factors within the = router eg: burst,  packet rate etc . So the application priority = can get lost.  Based on the QUIC stream priority, network elements = could remark the DSCP value to take a better = path.

=

 <= /o:p>

So, I recommended = you look at the document because it treats the problem of having a = single five(or six)-tuple flow have different markings.  Evidently, = your basic answer is to replace the current flow-state management with a = different view of the flow ("session"), using the stream id as = a demultiplexing signal.  You then wish to have a marking for the = session. 

One of the = design goals of QUIC is that it be deployable on the Internet as it = exists, rather than relying on features which must be introduced into = the network to support it.  This effort seems to run counter to = that design goal as well.

 <= /o:p>

We are not = proposing any remarking of the QUIC stream priority, but that it will = remain the same. We can add authentication to make sure the fields are = in tact. Also in DSCP case a single flow will usually be given the same = priority. In this case, the single flow/session can be given different = priorities on a per stream basis.

 <= /o:p>

 <= /o:p>

Of course, there = is a potential silly state here if the session-state aware network = elements do something on one signal and their non-session-state peers = act on a different signal; at best, you'd have to scrub and re-mark to = avoid that.  Given that, I fail to see why the multiple-markings = within a flow approach of RFC 7657 doesn't work at least as well, at = least for the Internet as currently = deployed.

regards,

Ted

 <= /o:p>

Thanks,=

Abilash=

 <= /o:p>

 <= /o:p>

Though = pointing primarily at RTP flows multiplexed using BUNDLE, I suspect many = of the lessons learned would apply to your efforts, whether you used = DSCP or a different = marking.

 <= /o:p>

regards,

Ted

 <= /p>

 <= /o:p>

On Thu, Jan = 5, 2017 at 7:34 AM, Ritesh Mukherjee <rmukherjee@128technology.com> = wrote:

Hi = Team,

 

We recently published = draft-abilash-quic-network-00 which proposes a change to the QUIC = protocol header that will allow network elements to prioritize streams = in QUIC packets, divert high priority streams to low loss paths, and = adjust packet pacing on a per stream basis. We have already received = some very positive comments from some members but wanted to solicit = feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary:&nbs= p;

 

URL:         &nbs= p; &nbs= p;https://www.ietf.org/internet-drafts/draft-abilash= -quic-network-00.txt

Htmlized:      &nbs= p;https://tools.ietf.org/html/draft-abilash-quic-net= work-00

 

Thank you in = advance!

 

Ritesh

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_01A6_01D26B20.09A6FD70-- From nobody Tue Jan 10 10: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 27414129451 for ; Tue, 10 Jan 2017 10:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 4Ix0KJmUFynC for ; Tue, 10 Jan 2017 10:34:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7674212940A for ; Tue, 10 Jan 2017 10:34:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEE45114; Tue, 10 Jan 2017 18:33:03 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 10 Jan 2017 18:33:02 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0301.000; Tue, 10 Jan 2017 10:32:59 -0800 From: Lin Han To: "'Abilash Menon'" Subject: RE: soliciting feedback on draft-abilash-quic-network Thread-Topic: soliciting feedback on draft-abilash-quic-network Thread-Index: AQHSaB8j7EFh+AryQuCJjvpLcGn68aEwl6wggACnEgCAAMrBgA== Date: Tue, 10 Jan 2017 18:32:58 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162B86F92A@dfweml501-mbb> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> In-Reply-To: <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.191] Content-Type: multipart/alternative; boundary="_000_1D30AF33624CDD4A99E8C395069A2A162B86F92Adfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58752928.02FF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fb0ae679fdc49ba71db0861a3474db12 Archived-At: Cc: Ritesh Mukherjee , Jana Iyengar , Ted Hardie , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:34:23 -0000 --_000_1D30AF33624CDD4A99E8C395069A2A162B86F92Adfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, What I meant is the capability that QUIC can carry the signaling informatio= n distributed for the network device on the path, the signaling information= will be intercepted at each hop when the QUIC packets are forwarded. The d= etailed signaling can be designed later by other RFC. As for how the networ= k device knows to start looking for QUIC is another topic which should rely= on the IP packet, and QUIC cannot do anything. Thanks Lin From: Abilash Menon [mailto:amenon@128technology.com] Sent: Monday, January 09, 2017 2:05 PM To: Lin Han Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network Lin, We had suggested priority and streamed as a starting point to get more netw= ork aware details from the application. When you say signaling - are you in= dicating signaling to setup the network elements to start looking for QUIC = packets or for something else. Please clarify. Thanks, Abilash On Jan 9, 2017, at 3:15 PM, Lin Han > wrote: Hi, Abilash I have a question which might be related to this topic. >From the point of view of network device, we want to know and also wish tha= t the QUIC could support the signaling for the network device along the pat= h. This is for the QoS enhancement consideration in the future. Marking priori= ty is not enough for provisioning a device. The lesson from TCP is its rigidity for the extension. It would be nice tha= t QUIC has such elastic from the beginning of the design. Thanks Lin From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Abilash Menon Sent: Friday, January 06, 2017 5:17 AM To: Jana Iyengar Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network Jana, Thank you for reviewing. Please see inline : On Jan 5, 2017, at 10:52 PM, Jana Iyengar > wrote: Hi, Thanks for writing up the draft -- as Patrick notes, it's helpful to have s= omething concrete to discuss. I have a number of thoughts as I catch up on this thread, but I have a high= -order one: have you considered proposing this draft for HTTP/2? Given that= the use of streams is basically the same for HTTP/2 and HTTP over QUIC, I = would expect that signaling stream IDs and priorities for HTTP/2 should be = similar. Why not propose it for HTTP/2? We did not consider that, but we certainly could. Thank you for the suggest= ion. There are a significant number of engineering issues with doing priorities = per stream, the most significant one being the one that Christian points ou= t: that congestion control and loss detection will need to be per-stream, d= efeating a major rationale for stream multiplexing. That is a show-stopper,= in my opinion. You'd have the same troubles with TCP and HTTP/2. So if you consider packet pacing with multiple streams, the latency of one = stream need not be affected by another if one specific stream gets affected= . Yes this would need per stream congestion control - it looks like you don= e want to have that granular control here. So is there any network assistan= ce you would like the protocol to get if the network elements can support i= t. If so , please let us know - we would like to understand. I don't think prioritizing streams by network elements makes good engineeri= ng sense. Prioritization could certainly help streams. That could use the RFC7657 whi= ch Ted had mentioned, but our approach was to leverage the QUIC protocol it= self to use priority and get more granular view of the network using stream= ids. We will see if we can get some useful results. Thanks, Abilash - jana On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie > wrote: Reply in-line. On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon > wrote: Hey Ted, Thanks for your feedback. Please see replies inline : On Jan 5, 2017, at 2:57 PM, Ted Hardie > wrote: Howdy, Forgive the top posting, but this seems to be a bit of meta-question. If I= read your draft correctly, you are suggesting that QUIC expose stream iden= tifiers and associate them with a priority, so that on-path devices may mov= e certain streams onto higher priority paths or otherwise give variable qua= lity of service. That is one use case yes. The on-path devices can provide quality of servic= es on a per stream basis. For this to work correctly, though, the basic aim of multiplexing seems to = be changed as you could not multiplex streams into the same packet, even if= they have the same desired network treatment. At that level of isolation,= independent QUIC connections may suit your use cases just as well (if, ind= eed, you would choose QUIC at all). If that is the required level of indep= endence, why does opening different connections not work as well? Using stream1, the connection gets established and the headers get exchange= d using stream 3. Opening multiple connections would incur more latency for= the connection setup. So with one QUIC connection, multiple streams can le= verage the same connection without taking the hit of the connection establi= shment latency for each stream. With 0RTT, this is probably not an issue for a long-lived flows, and it has= to be compared to the cost for application mechanics to make sure that eac= h packet contains elements from only a single stream. For a multiplexing p= rotocol, the latter seems fundamentally sub-optimal. It's also not clear why you need that level of independence. At the very le= ast, your description makes it seem that you could multiplex streams whose = desired network treatment is the same. And, if you did multiplex streams w= ith the same desired network treatment, there seems to be no need at all to= expose the stream identifiers (after all, you might have more than one str= eam in a packet). Stream id being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing mecha= nism will also benefit from this as it can be done a per stream basis and n= ot for the whole connection. So, "building the QUIC state machine in the network elements" doesn't mean = much absent a knowledge of what those network elements are going to do with= the state. The use case that you mentioned originally, path selection for= network treatment, doesn't actually require that the on-path elements dist= inguish among streams that require like treatment. It simply requires that= the requested network treatment be visible. Given that multiplexing strea= ms that require like network treatment works with the multiplexed design of= QUIC, I'm still unclear why you want to insist on such a strict independen= ce. Instead, you would only need to expose the desired network treatment for = a specific packet. Why is that not enough to meet the need and why, if tha= t is the case, would differentiated DSCP markings not meet your needs? Yes. Network treatment of a packet (priority) is definitely needed. Stream = id being exposed would help build QUIC state machine in the network element= s for each stream as mentioned in the draft. The packet pacing mechanism wi= ll also benefit from this as it can be done a per stream basis and not for = the whole connection. Your draft says this: However, session aware routers will have a flow per stream. Hence the packet rate can be adjusted on a per stream basis and not for the whole connection. Once again, this seems to run counter to the design of a multiplexed protoc= ol, and the description in the document is a bit circular. A session aware= router certainly would not have a flow per stream as QUIC is designed now;= it would have no way to create such a flow. You are motivating the change= in QUIC in order to achieve that for session aware routers, but without ad= dressing the loss of other basic QUIC design features. Also, the stream priority would be used to send among multiple paths in mul= ti path case. On the latter case, there was good bit of discussion on how well multiple D= SCP markings on a single 5-tuple would work in the context of WEBRTC; if yo= u have not read RFC 7657, I would suggest doing so, along with draft-ietf-t= svwg-rtcweb-qos. DSCP may not always guarantee the quality of service as it could be remarke= d by the routers in between. It also depends on other factors within the ro= uter eg: burst, packet rate etc . So the application priority can get lost= . Based on the QUIC stream priority, network elements could remark the DSC= P value to take a better path. So, I recommended you look at the document because it treats the problem of= having a single five(or six)-tuple flow have different markings. Evidentl= y, your basic answer is to replace the current flow-state management with a= different view of the flow ("session"), using the stream id as a demultipl= exing signal. You then wish to have a marking for the session. One of the design goals of QUIC is that it be deployable on the Internet as= it exists, rather than relying on features which must be introduced into t= he network to support it. This effort seems to run counter to that design = goal as well. We are not proposing any remarking of the QUIC stream priority, but that it= will remain the same. We can add authentication to make sure the fields ar= e in tact. Also in DSCP case a single flow will usually be given the same p= riority. In this case, the single flow/session can be given different prior= ities on a per stream basis. Of course, there is a potential silly state here if the session-state aware= network elements do something on one signal and their non-session-state pe= ers act on a different signal; at best, you'd have to scrub and re-mark to = avoid that. Given that, I fail to see why the multiple-markings within a f= low approach of RFC 7657 doesn't work at least as well, at least for the In= ternet as currently deployed. regards, Ted Thanks, Abilash Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect = many of the lessons learned would apply to your efforts, whether you used D= SCP or a different marking. regards, Ted On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee > wrote: Hi Team, We recently published draft-abilash-quic-network-00 which proposes a change= to the QUIC protocol header that will allow network elements to prioritize= streams in QUIC packets, divert high priority streams to low loss paths, a= nd adjust packet pacing on a per stream basis. We have already received som= e very positive comments from some members but wanted to solicit feedback f= rom the larger community. Please provide your comments/feedback/recommendat= ions as necessary: URL: https://www.ietf.org/internet-drafts/draft-abilash-quic-net= work-00.txt Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 Thank you in advance! Ritesh --_000_1D30AF33624CDD4A99E8C395069A2A162B86F92Adfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

What I meant is the capab= ility that QUIC can carry the signaling information distributed for the net= work device on the path, the signaling information will be intercepted at each hop when the QUIC packets are forwarded. The detail= ed signaling can be designed later by other RFC. As for how the network dev= ice knows to start looking for QUIC is another topic which should rely on t= he IP packet, and QUIC cannot do anything.

 <= /p>

Thanks<= /p>

 <= /p>

Lin

 <= /p>

From: Abilash = Menon [mailto:amenon@128technology.com]
Sent: Monday, January 09, 2017 2:05 PM
To: Lin Han
Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on draft-abilash-quic-network<= /o:p>

 

Lin,

 

We had suggested priority and streamed as a starting= point to get more network aware details from the application. When you say= signaling - are you indicating signaling to setup the network elements to = start looking for QUIC packets or for something else. Please clarify.

 

Thanks,

Abilash

 

On Jan 9, 2017, at 3:15 PM, Lin Han <Lin.Han@huawei.com> wrote:

 

Hi, Abilash

 <= /p>

I have a question which m= ight be related to this topic.

 <= /p>

From the point of view of= network device, we want to know and also wish that the QUIC could support = the signaling for the network device along the path.

This is for the QoS enhan= cement consideration in the future. Marking priority is not enough for prov= isioning a device.

The lesson from TCP is it= s rigidity for the extension. It would be nice that QUIC has such elastic f= rom the beginning of the design.

 <= /p>

Thanks<= /p>

 <= /p>

Lin

 <= /p>

From: QUIC [mailto:quic-bounces@ietf.org= ] On Behalf Of Abilash Menon
Sent: Friday, Janu= ary 06, 2017 5:17 AM
To: Jana Iyengar Cc: Ritesh Mukherj= ee; Ted Hardie; IETF QUIC WG
Subject: Re: solic= iting feedback on draft-abilash-quic-network

 

Jana,

 

Thank you for reviewing. Please see inline :

 

On Jan 5, 2017, at 10:52 PM, Jana Iyengar <jri@google.com> wrote:

 

Hi,

 

Thanks for writing up the draft -- as Patrick notes,= it's helpful to have something concrete to discuss.

 

I have a number of thoughts as I catch up on this th= read, but I have a high-order one: have you considered proposing this draft= for HTTP/2? Given that the use of streams is basically the same for HTTP/2= and HTTP over QUIC, I would expect that signaling stream IDs and priorities for HTTP/2 should be similar. Why= not propose it for HTTP/2?

 

We did not consider that, but we certainly could. Th= ank you for the suggestion.




 

There are a significant number of engineering issues= with doing priorities per stream, the most significant one being the one t= hat Christian points out: that congestion control and loss detection will n= eed to be per-stream, defeating a major rationale for stream multiplexing. That is a show-stopper, in my opi= nion. You'd have the same troubles with TCP and HTTP/2.

 

So if you consider packet pacing with multiple strea= ms, the latency of one stream need not be affected by another if one specif= ic stream gets affected. Yes this would need per stream congestion control = - it looks like you done want to have that granular control here. So is there any network assistance you would l= ike the protocol to get if the network elements can support it. If so , ple= ase let us know - we would like to understand. 




 

I don't think prioritizing streams by network elemen= ts makes good engineering sense.

 

Prioritization could certainly help streams. That co= uld use the RFC7657 which Ted had mentioned, but our approach was to levera= ge the QUIC protocol itself to use priority and get more granular view of t= he network using stream ids. We will see if we can get some useful results.

 

Thanks,

Abilash

 




 

- jana

 

 

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Reply in-line.

 

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <amenon@128technology.com> wrote:

Hey Ted,

 

Thanks for your feedback. Please see replies inline = :

 

On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

 

Howdy,

Forgive the top posting, but this seems to be a bit = of meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, so = that on-path devices may move certain streams onto higher priority paths or otherwise give variable quality of service.<= o:p>

 

That is one use case yes. The on-path devices can pr= ovide quality of services on a per stream basis. 




 

For this to work correctly, though, the basic aim of= multiplexing seems to be changed as you could not multiplex streams into t= he same packet, even if they have the same desired network treatment. = At that level of isolation, independent QUIC connections may suit your use cases just as well (if, indeed, you wou= ld choose QUIC at all).  If that is the required level of independence= , why does opening different connections not work as well?

 

Using stream1, the connection gets established and t= he headers get exchanged using stream 3. Opening multiple connections would= incur more latency for the connection setup. So with one QUIC connection, = multiple streams can leverage the same connection without taking the hit of the connection establishment lat= ency for each stream.

 

With 0RTT, this is probably not an issue for a long-= lived flows, and it has to be compared to the cost for application mechanic= s to make sure that each packet contains elements from only a single stream= .  For a multiplexing protocol, the latter seems fundamentally sub-optimal.

 





It's also not clear why you need that level of independence. At the very le= ast, your description makes it seem that you could multiplex streams whose = desired network treatment is the same.  And, if you did multiplex stre= ams with the same desired network treatment, there seems to be no need at all to expose the stream identifiers (after a= ll, you might have more than one stream in a packet).

 

Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the draft. = The packet pacing mechanism will also benefit from this as it can be done a= per stream basis and not for the whole connection. 

 

 

So, "building the QUIC state machine in the net= work elements" doesn't mean much absent a knowledge of what those netw= ork elements are going to do with the state.  The use case that you me= ntioned originally, path selection for network treatment, doesn't actually require that the on-path elements distinguish among strea= ms that require like treatment.  It simply requires that the requested= network treatment be visible.  Given that multiplexing streams that r= equire like network treatment works with the multiplexed design of QUIC, I'm still unclear why you want to insist on su= ch a strict independence.

 

  Instead, you would only need to expose the de= sired network treatment for a specific packet.  Why is that not enough= to meet the need and why, if that is the case, would differentiated DSCP m= arkings not meet your needs?

 

Yes. Network treatment of a packet (priority) is def= initely needed. Stream id being exposed would help build QUIC state machine= in the network elements for each stream as mentioned in the draft. The pac= ket pacing mechanism will also benefit from this as it can be done a per stream basis and not for the whole conne= ction.

 

Your draft says this:= 

   However, session aware routers will have a flow per<=
/o:p>
   stream.  Hence the packet rate can be adjusted on a =
per stream basis
   and not for the whole connection.

Once again, this seems to run counter to the design = of a multiplexed protocol, and the description in the document is a bit cir= cular.  A session aware router certainly would not have a flow per str= eam as QUIC is designed now; it would have no way to create such a flow.  You are motivating the change in QUIC = in order to achieve that for session aware routers, but without addressing = the loss of other basic QUIC design features.

 

Also, the stream priority would be used to send amon= g multiple paths in multi path case. 

 


 

 

On the latter case, there was good bit of discussion= on how well multiple DSCP markings on a single 5-tuple would work in the c= ontext of WEBRTC; if you have not read RFC 7657, I would suggest doing so, = along with draft-ietf-tsvwg-rtcweb-qos. 

 

DSCP may not always guarantee the quality of service= as it could be remarked by the routers in between. It also depends on othe= r factors within the router eg: burst,  packet rate etc . So the appli= cation priority can get lost.  Based on the QUIC stream priority, network elements could remark the DSCP value to = take a better path.

 

So, I recommended you= look at the document because it treats the problem of having a single five= (or six)-tuple flow have different markings.  Evidently, your basic an= swer is to replace the current flow-state management with a different view of the flow ("session"), using = the stream id as a demultiplexing signal.  You then wish to have a mar= king for the session. 

One of the design goals of QUIC is that it be deploy= able on the Internet as it exists, rather than relying on features which mu= st be introduced into the network to support it.  This effort seems to= run counter to that design goal as well.

 

We are not proposing any remarking of the QUIC strea= m priority, but that it will remain the same. We can add authentication to = make sure the fields are in tact. Also in DSCP case a single flow will usua= lly be given the same priority. In this case, the single flow/session can be given different priorities on a = per stream basis.

 

 

Of course, there is a= potential silly state here if the session-state aware network elements do = something on one signal and their non-session-state peers act on a differen= t signal; at best, you'd have to scrub and re-mark to avoid that.  Given that, I fail to see why the multipl= e-markings within a flow approach of RFC 7657 doesn't work at least as well= , at least for the Internet as currently deployed.

regards,

Ted

 

Thanks,

Abilash

 

 

Though pointing primarily at RTP flows multiplexed u= sing BUNDLE, I suspect many of the lessons learned would apply to your effo= rts, whether you used DSCP or a different marking.

 

regards,

Ted

 

 

On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee <= ;rmukherjee@128technology.com> wrote:

Hi Team,

 

We recently published draft-abilash-quic-network-00 which proposes a c= hange to the QUIC protocol header that will allow network elements to prior= itize streams in QUIC packets, divert high priority streams to low loss paths, and adjust packet pacing on a per stream basis.= We have already received some very positive comments from some members but= wanted to solicit feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary: 

 

URL:            https://www.ietf.org/internet-drafts/draft-abilas= h-quic-network-00.txt

Htmlized:       https://tool= s.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in advance!

 

Ritesh

 

--_000_1D30AF33624CDD4A99E8C395069A2A162B86F92Adfweml501mbb_-- From nobody Tue Jan 10 10:47: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 D1610129546 for ; Tue, 10 Jan 2017 10:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 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, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=128technology-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 QfNuVtz5l4oj for ; Tue, 10 Jan 2017 10:47:29 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8734129543 for ; Tue, 10 Jan 2017 10:47:28 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id s140so161556969qke.0 for ; Tue, 10 Jan 2017 10:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=oDO3Lnnz2ur4NoeM5WJOFaPaiaEuZRpSNMF0yegJlKs=; b=jtKLfKkRv0OWKwJWpdyYFXSTJwJHUFeqDwT2HL2k4z6NOAv4EAL0SJIifJB8CLaYnk CuHtKjMeaKSIfnl4fv4kA7TeHdB/OHMwM4HaQF7y8NfzCVPKsIna7U3o30LWSBIc8+yr HlGiZ/4+7GHhaFVPLxBaQmt1Dv7pRa4K5YeZNPOmHTVeN2kYnup/yJlHnVcR7+nUCErO kseXfObLZvFYJjf2WcSO19XLMe+zeECHPMndTh7YnMNoLwj5Cfd0UY0KP01Rd7o+2bkG 6aaS3iJmq6R5rzPhVp4q+/f0xG6N3UVVNYs2orzo0iCq00ri0zfPriOyH0046WnPF+y9 TM9A== 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 :message-id:references:to; bh=oDO3Lnnz2ur4NoeM5WJOFaPaiaEuZRpSNMF0yegJlKs=; b=op+4uXcC0XSk1p4WFknDEnsGAzjbcQCiHFcTBv8gdpUUrn+Ba+A2kqLaylVH8ijV9J 4gkznHfmWrfmZvg9RkEPXIUrtptwroxYM7tAv4FiP6aHKXhKmRQPxo+WngqWCjLXQJQN LnZ2+Dv0TxCVxzQbvFdIh/GRIPr2QVOzBsvXoCKA0dGaWfNz+PNScsxIK0DD78z+VMYo 1KpiyxDwteKGRin1/RLfOemAqKODemiogQxPhYYt/iiXHp9FVNAOVqDJfdj1p6S+J3kt EISII/FhXUX/0tFfsZQPMhDnMIs69rujLL0U3RtSWFZ2L7Vkch+L576nN8T/Tj5T8Zv9 vq8g== X-Gm-Message-State: AIkVDXJ6osSrS8jxN2Agxx1IhLZLv9Qvh1flIEBMMxqNZGTyuAdbjarXS7O+quYxLj1o8Jo6 X-Received: by 10.55.74.21 with SMTP id x21mr4164866qka.46.1484074047710; Tue, 10 Jan 2017 10:47:27 -0800 (PST) Received: from [10.0.2.25] ([172.85.50.34]) by smtp.gmail.com with ESMTPSA id u49sm2031265qtc.44.2017.01.10.10.47.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Jan 2017 10:47:27 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C6CAC055-88AD-483E-B958-B99C379DD642" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: soliciting feedback on draft-abilash-quic-network From: Abilash Menon In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162B86F92A@dfweml501-mbb> Date: Tue, 10 Jan 2017 13:47:26 -0500 Message-Id: <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F92A@dfweml501-mbb> To: Lin Han X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , Jana Iyengar , Ted Hardie , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:47:32 -0000 --Apple-Mail=_C6CAC055-88AD-483E-B958-B99C379DD642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lin, Thanks. What is the signaling information carrying though. I think you = are alluding to some kind of metadata/header that QUIC can carry which = is public ? I did not quite understand your use case though. Another = option would be to have an optional tlv after the public headers where = application can add any app specific data. The Type would need further = discussion though. This could be signaling, identifier or anything for = the network elements - a network element header.=20 Jana, It looks like there is sufficient interest for sending information to = the network elements via the QUIC packet. There may be multiple use = cases and we can probably work towards a consensus by not violating any = of the chart goals. Can we discuss this during some upcoming meeting = with the interested parties.=20 All, Please let us know if there are others who are interested in the network = elements being QUIC aware. We could probably work together to discuss = use cases and have a more in-depth technical discussion with Jana and = others. Thanks, Abilash > On Jan 10, 2017, at 1:32 PM, Lin Han wrote: >=20 > Hi, > =20 > What I meant is the capability that QUIC can carry the signaling = information distributed for the network device on the path, the = signaling information will be intercepted at each hop when the QUIC = packets are forwarded. The detailed signaling can be designed later by = other RFC. As for how the network device knows to start looking for QUIC = is another topic which should rely on the IP packet, and QUIC cannot do = anything. > =20 > Thanks > =20 > Lin > =20 > From: Abilash Menon [mailto:amenon@128technology.com]=20 > Sent: Monday, January 09, 2017 2:05 PM > To: Lin Han > Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG > Subject: Re: soliciting feedback on draft-abilash-quic-network > =20 > Lin, > =20 > We had suggested priority and streamed as a starting point to get more = network aware details from the application. When you say signaling - are = you indicating signaling to setup the network elements to start looking = for QUIC packets or for something else. Please clarify. > =20 > Thanks, > Abilash > =20 > On Jan 9, 2017, at 3:15 PM, Lin Han > wrote: > =20 > Hi, Abilash > =20 > I have a question which might be related to this topic. > =20 > =46rom the point of view of network device, we want to know and also = wish that the QUIC could support the signaling for the network device = along the path. > This is for the QoS enhancement consideration in the future. Marking = priority is not enough for provisioning a device. > The lesson from TCP is its rigidity for the extension. It would be = nice that QUIC has such elastic from the beginning of the design. > =20 > Thanks > =20 > Lin > =20 > From: QUIC [mailto:quic-bounces@ietf.org = ] On Behalf Of Abilash Menon > Sent: Friday, January 06, 2017 5:17 AM > To: Jana Iyengar > Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG > Subject: Re: soliciting feedback on draft-abilash-quic-network > =20 > Jana, > =20 > Thank you for reviewing. Please see inline : > =20 > On Jan 5, 2017, at 10:52 PM, Jana Iyengar > wrote: > =20 > Hi, > =20 > Thanks for writing up the draft -- as Patrick notes, it's helpful to = have something concrete to discuss. > =20 > I have a number of thoughts as I catch up on this thread, but I have a = high-order one: have you considered proposing this draft for HTTP/2? = Given that the use of streams is basically the same for HTTP/2 and HTTP = over QUIC, I would expect that signaling stream IDs and priorities for = HTTP/2 should be similar. Why not propose it for HTTP/2? > =20 > We did not consider that, but we certainly could. Thank you for the = suggestion. >=20 >=20 >=20 > =20 > There are a significant number of engineering issues with doing = priorities per stream, the most significant one being the one that = Christian points out: that congestion control and loss detection will = need to be per-stream, defeating a major rationale for stream = multiplexing. That is a show-stopper, in my opinion. You'd have the same = troubles with TCP and HTTP/2. > =20 > So if you consider packet pacing with multiple streams, the latency of = one stream need not be affected by another if one specific stream gets = affected. Yes this would need per stream congestion control - it looks = like you done want to have that granular control here. So is there any = network assistance you would like the protocol to get if the network = elements can support it. If so , please let us know - we would like to = understand.=20 >=20 >=20 >=20 > =20 > I don't think prioritizing streams by network elements makes good = engineering sense. > =20 > Prioritization could certainly help streams. That could use the = RFC7657 which Ted had mentioned, but our approach was to leverage the = QUIC protocol itself to use priority and get more granular view of the = network using stream ids. We will see if we can get some useful results. > =20 > Thanks, > Abilash > =20 >=20 >=20 >=20 > =20 > - jana > =20 > =20 > On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie > wrote: > Reply in-line. > =20 > On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon = > wrote: > Hey Ted, > =20 > Thanks for your feedback. Please see replies inline : > =20 > On Jan 5, 2017, at 2:57 PM, Ted Hardie > wrote: > =20 > Howdy, >=20 > Forgive the top posting, but this seems to be a bit of meta-question. = If I read your draft correctly, you are suggesting that QUIC expose = stream identifiers and associate them with a priority, so that on-path = devices may move certain streams onto higher priority paths or otherwise = give variable quality of service. > =20 > That is one use case yes. The on-path devices can provide quality of = services on a per stream basis.=20 >=20 >=20 >=20 > =20 > For this to work correctly, though, the basic aim of multiplexing = seems to be changed as you could not multiplex streams into the same = packet, even if they have the same desired network treatment. At that = level of isolation, independent QUIC connections may suit your use cases = just as well (if, indeed, you would choose QUIC at all). If that is the = required level of independence, why does opening different connections = not work as well? > =20 > Using stream1, the connection gets established and the headers get = exchanged using stream 3. Opening multiple connections would incur more = latency for the connection setup. So with one QUIC connection, multiple = streams can leverage the same connection without taking the hit of the = connection establishment latency for each stream. > =20 > With 0RTT, this is probably not an issue for a long-lived flows, and = it has to be compared to the cost for application mechanics to make sure = that each packet contains elements from only a single stream. For a = multiplexing protocol, the latter seems fundamentally sub-optimal. > =20 >=20 >=20 >=20 >=20 > It's also not clear why you need that level of independence. At the = very least, your description makes it seem that you could multiplex = streams whose desired network treatment is the same. And, if you did = multiplex streams with the same desired network treatment, there seems = to be no need at all to expose the stream identifiers (after all, you = might have more than one stream in a packet). > =20 > Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection.=20 > =20 > =20 > So, "building the QUIC state machine in the network elements" doesn't = mean much absent a knowledge of what those network elements are going to = do with the state. The use case that you mentioned originally, path = selection for network treatment, doesn't actually require that the = on-path elements distinguish among streams that require like treatment. = It simply requires that the requested network treatment be visible. = Given that multiplexing streams that require like network treatment = works with the multiplexed design of QUIC, I'm still unclear why you = want to insist on such a strict independence. > =20 > Instead, you would only need to expose the desired network treatment = for a specific packet. Why is that not enough to meet the need and why, = if that is the case, would differentiated DSCP markings not meet your = needs? > =20 > Yes. Network treatment of a packet (priority) is definitely needed. = Stream id being exposed would help build QUIC state machine in the = network elements for each stream as mentioned in the draft. The packet = pacing mechanism will also benefit from this as it can be done a per = stream basis and not for the whole connection. > =20 > Your draft says this: >=20 > However, session aware routers will have a flow per > stream. Hence the packet rate can be adjusted on a per stream = basis > and not for the whole connection. > Once again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular. A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow. You are = motivating the change in QUIC in order to achieve that for session aware = routers, but without addressing the loss of other basic QUIC design = features. > =20 > Also, the stream priority would be used to send among multiple paths = in multi path case.=20 > =20 >=20 > =20 > =20 > On the latter case, there was good bit of discussion on how well = multiple DSCP markings on a single 5-tuple would work in the context of = WEBRTC; if you have not read RFC 7657, I would suggest doing so, along = with draft-ietf-tsvwg-rtcweb-qos.=20 > =20 > DSCP may not always guarantee the quality of service as it could be = remarked by the routers in between. It also depends on other factors = within the router eg: burst, packet rate etc . So the application = priority can get lost. Based on the QUIC stream priority, network = elements could remark the DSCP value to take a better path. > =20 > So, I recommended you look at the document because it treats the = problem of having a single five(or six)-tuple flow have different = markings. Evidently, your basic answer is to replace the current = flow-state management with a different view of the flow ("session"), = using the stream id as a demultiplexing signal. You then wish to have a = marking for the session.=20 >=20 > One of the design goals of QUIC is that it be deployable on the = Internet as it exists, rather than relying on features which must be = introduced into the network to support it. This effort seems to run = counter to that design goal as well. > =20 > We are not proposing any remarking of the QUIC stream priority, but = that it will remain the same. We can add authentication to make sure the = fields are in tact. Also in DSCP case a single flow will usually be = given the same priority. In this case, the single flow/session can be = given different priorities on a per stream basis. > =20 > =20 > Of course, there is a potential silly state here if the session-state = aware network elements do something on one signal and their = non-session-state peers act on a different signal; at best, you'd have = to scrub and re-mark to avoid that. Given that, I fail to see why the = multiple-markings within a flow approach of RFC 7657 doesn't work at = least as well, at least for the Internet as currently deployed. >=20 > regards, >=20 > Ted > =20 > Thanks, > Abilash > =20 > =20 > Though pointing primarily at RTP flows multiplexed using BUNDLE, I = suspect many of the lessons learned would apply to your efforts, whether = you used DSCP or a different marking. > =20 > regards, >=20 > Ted > =20 >=20 > =20 > On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee = > = wrote: > Hi Team, > =20 > We recently published draft-abilash-quic-network-00 which proposes a = change to the QUIC protocol header that will allow network elements to = prioritize streams in QUIC packets, divert high priority streams to low = loss paths, and adjust packet pacing on a per stream basis. We have = already received some very positive comments from some members but = wanted to solicit feedback from the larger community. Please provide = your comments/feedback/recommendations as necessary:=20 > =20 >=20 > URL: = https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt = > Htmlized: = https://tools.ietf.org/html/draft-abilash-quic-network-00 = > =20 > Thank you in advance! > =20 > Ritesh --Apple-Mail=_C6CAC055-88AD-483E-B958-B99C379DD642 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Lin,

Thanks. What is the signaling information carrying though. I = think you are alluding to some kind of metadata/header that QUIC can = carry which is public ?  I did not quite understand your use case = though. Another option would be to have an optional tlv after the public = headers where application can add any app specific data.  The Type = would need further discussion though. This could be signaling, = identifier or anything for the network elements - a network element = header. 

Jana,

It looks like there is sufficient interest for sending = information to the network elements via the QUIC packet. There may be = multiple use cases and we can probably work towards a consensus by not = violating any of the chart goals. Can we discuss this during some = upcoming meeting with the interested parties. 

All,

Please let us know if = there are others who are interested in the network elements being QUIC = aware. We could probably work together to discuss use cases and have a = more in-depth technical discussion with Jana and others.

Thanks,
Abilash

On Jan 10, 2017, at 1:32 PM, = Lin Han <Lin.Han@huawei.com> wrote:

Hi,
 
What I meant is the = capability that QUIC can carry the signaling information distributed for = the network device on the path, the signaling information will be = intercepted at each hop when the QUIC packets are forwarded. The = detailed signaling can be designed later by other RFC. As for how the = network device knows to start looking for QUIC is another topic which = should rely on the IP packet, and QUIC cannot do anything.
 
Thanks
 
Lin
 
From: Abilash = Menon [mailto:amenon@128technology.com] 
Sent: Monday, January 09, 2017 = 2:05 PM
To: Lin Han
Cc: Jana = Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on = draft-abilash-quic-network
 
Lin,
 
We had suggested priority and streamed as a starting = point to get more network aware details from the application. When you = say signaling - are you indicating signaling to setup the network = elements to start looking for QUIC packets or for something else. Please = clarify.
 
Thanks,
Abilash
 
On Jan 9, 2017, at = 3:15 PM, Lin Han <Lin.Han@huawei.com> wrote:
 
Hi,= Abilash
 
I have a question which might be related = to this topic.
 
=46rom the point of = view of network device, we want to know and also wish that the QUIC = could support the signaling for the network device along the = path.
This is for the QoS enhancement consideration in the future. = Marking priority is not enough for provisioning a device.
The lesson from TCP is = its rigidity for the extension. It would be nice that QUIC has such = elastic from the beginning of the design.
 
Thanks
 
Lin
 
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Abilash = Menon
Sent: Friday, January 06, 2017 = 5:17 AM
To: Jana Iyengar
Cc: Ritesh Mukherjee; Ted = Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on = draft-abilash-quic-network
 
Jana,
 
Thank you for reviewing. Please see = inline :
 
On = Jan 5, 2017, at 10:52 PM, Jana Iyengar <jri@google.com> wrote:
 
Hi,
 
Thanks for writing up the draft -- as = Patrick notes, it's helpful to have something concrete to discuss.
 
I have a number of thoughts as I catch up = on this thread, but I have a high-order one: have you considered = proposing this draft for HTTP/2? Given that the use of streams is = basically the same for HTTP/2 and HTTP over QUIC, I would expect that = signaling stream IDs and priorities for HTTP/2 should be similar. Why = not propose it for HTTP/2?
 
We = did not consider that, but we certainly could. Thank you for the = suggestion.



 
There = are a significant number of engineering issues with doing priorities per = stream, the most significant one being the one that Christian points = out: that congestion control and loss detection will need to be = per-stream, defeating a major rationale for stream multiplexing. That is = a show-stopper, in my opinion. You'd have the same troubles with TCP and = HTTP/2.
 
So = if you consider packet pacing with multiple streams, the latency of one = stream need not be affected by another if one specific stream gets = affected. Yes this would need per stream congestion control - it looks = like you done want to have that granular control here. So is there any = network assistance you would like the protocol to get if the network = elements can support it. If so , please let us know - we would like to = understand. 



 
I don't think prioritizing streams by = network elements makes good engineering sense.
 
Prioritization could certainly help = streams. That could use the RFC7657 which Ted had mentioned, but our = approach was to leverage the QUIC protocol itself to use priority and = get more granular view of the network using stream ids. We will see if = we can get some useful results.
 
Thanks,
Abilash
 



 
- = jana
 
 
On Thu, Jan 5, 2017 at 4:08 PM, Ted = Hardie <ted.ietf@gmail.com> = wrote:
Reply in-line.
 
On Thu, Jan 5, 2017 at 3:38 PM, Abilash = Menon <amenon@128technology.com> wrote:
Hey Ted,
 
Thanks for your feedback. Please see = replies inline :
 
On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
 

Howdy,

Forgive the top posting, but this seems to be a bit of = meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, = so that on-path devices may move certain streams onto higher priority = paths or otherwise give variable quality of service.
 
That = is one use case yes. The on-path devices can provide quality of services = on a per stream basis. 



 
For this to work correctly, though, the basic aim of = multiplexing seems to be changed as you could not multiplex streams into = the same packet, even if they have the same desired network = treatment.  At that level of isolation, independent QUIC = connections may suit your use cases just as well (if, indeed, you would = choose QUIC at all).  If that is the required level of = independence, why does opening different connections not work as = well?
 
Using = stream1, the connection gets established and the headers get exchanged = using stream 3. Opening multiple connections would incur more latency = for the connection setup. So with one QUIC connection, multiple streams = can leverage the same connection without taking the hit of the = connection establishment latency for each stream.
 
With 0RTT, this is probably not an issue = for a long-lived flows, and it has to be compared to the cost for = application mechanics to make sure that each packet contains elements = from only a single stream.  For a multiplexing protocol, the latter = seems fundamentally sub-optimal.
 




It's also not clear why = you need that level of independence. At the very least, your description = makes it seem that you could multiplex streams whose desired network = treatment is the same.  And, if you did multiplex streams with the = same desired network treatment, there seems to be no need at all to = expose the stream identifiers (after all, you might have more than one = stream in a packet).
 
Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the = draft. The packet pacing mechanism will also benefit from this as it can = be done a per stream basis and not for the whole connection. 
 
 
So, = "building the QUIC state machine in the network elements" doesn't mean = much absent a knowledge of what those network elements are going to do = with the state.  The use case that you mentioned originally, path = selection for network treatment, doesn't actually require that the = on-path elements distinguish among streams that require like = treatment.  It simply requires that the requested network treatment = be visible.  Given that multiplexing streams that require like = network treatment works with the multiplexed design of QUIC, I'm still = unclear why you want to insist on such a strict independence.
 
  Instead, you = would only need to expose the desired network treatment for a specific = packet.  Why is that not enough to meet the need and why, if that = is the case, would differentiated DSCP markings not meet your needs?
 
Yes. = Network treatment of a packet (priority) is definitely needed. Stream id = being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing = mechanism will also benefit from this as it can be done a per stream = basis and not for the whole connection.
 

Your draft says = this:

   =
However, session aware routers will have a flow per
   =
stream.  Hence the packet rate can be adjusted on a per stream =
basis
   =
and not for the whole connection.
Once = again, this seems to run counter to the design of a multiplexed = protocol, and the description in the document is a bit circular.  A = session aware router certainly would not have a flow per stream as QUIC = is designed now; it would have no way to create such a flow.  You = are motivating the change in QUIC in order to achieve that for session = aware routers, but without addressing the loss of other basic QUIC = design features.
 
Also, the stream priority would be used to send among = multiple paths in multi path case. 
 

 
 
On the latter case, there was good bit of = discussion on how well multiple DSCP markings on a single 5-tuple would = work in the context of WEBRTC; if you have not read RFC 7657, I would = suggest doing so, along with draft-ietf-tsvwg-rtcweb-qos. 
 
DSCP = may not always guarantee the quality of service as it could be remarked = by the routers in between. It also depends on other factors within the = router eg: burst,  packet rate etc . So the application priority = can get lost.  Based on the QUIC stream priority, network elements = could remark the DSCP value to take a better path.
 

So, I = recommended you look at the document because it treats the problem of = having a single five(or six)-tuple flow have different markings.  = Evidently, your basic answer is to replace the current flow-state = management with a different view of the flow ("session"), using the = stream id as a demultiplexing signal.  You then wish to have a = marking for the session. 

One = of the design goals of QUIC is that it be deployable on the Internet as = it exists, rather than relying on features which must be introduced into = the network to support it.  This effort seems to run counter to = that design goal as well.
 
We are not proposing any remarking of the QUIC stream = priority, but that it will remain the same. We can add authentication to = make sure the fields are in tact. Also in DSCP case a single flow will = usually be given the same priority. In this case, the single = flow/session can be given different priorities on a per stream = basis.
 
 

Of course, there is a potential = silly state here if the session-state aware network elements do = something on one signal and their non-session-state peers act on a = different signal; at best, you'd have to scrub and re-mark to avoid = that.  Given that, I fail to see why the multiple-markings within a = flow approach of RFC 7657 doesn't work at least as well, at least for = the Internet as currently deployed.

regards,

Ted
 
Thanks,
Abilash
 
 
Though pointing primarily at RTP flows = multiplexed using BUNDLE, I suspect many of the lessons learned would = apply to your efforts, whether you used DSCP or a different marking.
 

regards,

Ted

 

 
On Thu, Jan 5, 2017 at 7:34 AM, Ritesh = Mukherjee <rmukherjee@128technology.com> wrote:
Hi = Team,
 
We recently = published draft-abilash-quic-network-00 which proposes a change to the = QUIC protocol header that will allow network elements to prioritize = streams in QUIC packets, divert high priority streams to low loss paths, = and adjust packet pacing on a per stream basis. We have already received = some very positive comments from some members but wanted to solicit = feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary: 

 

URL:          &n= bsp; https://www.ietf.org/internet-drafts/draft-abilash-quic-network= -00.txt

Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

 
Thank you in = advance!
 
Ritesh

= --Apple-Mail=_C6CAC055-88AD-483E-B958-B99C379DD642-- From nobody Tue Jan 10 11:05: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 23189128B38 for ; Tue, 10 Jan 2017 11:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 NfbVDFr8cX6Y for ; Tue, 10 Jan 2017 11:05:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8253B12957A for ; Tue, 10 Jan 2017 11:05:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEE47893; Tue, 10 Jan 2017 19:05:50 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 10 Jan 2017 19:05:49 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Tue, 10 Jan 2017 11:05:24 -0800 From: Lin Han To: "'Abilash Menon'" Subject: RE: soliciting feedback on draft-abilash-quic-network Thread-Topic: soliciting feedback on draft-abilash-quic-network Thread-Index: AQHSaB8j7EFh+AryQuCJjvpLcGn68aEwl6wggACnEgCAAMrBgIAAkFgA//9+mIA= Date: Tue, 10 Jan 2017 19:05:23 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162B86F986@dfweml501-mbb> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F92A@dfweml501-mbb> <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> In-Reply-To: <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.191] Content-Type: multipart/alternative; boundary="_000_1D30AF33624CDD4A99E8C395069A2A162B86F986dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5875308F.0302, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fb0ae679fdc49ba71db0861a3474db12 Archived-At: Cc: Ritesh Mukherjee , Jana Iyengar , Ted Hardie , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 19:05:58 -0000 --_000_1D30AF33624CDD4A99E8C395069A2A162B86F986dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The signaling information is some QoS related information for the device pr= ogramming. Metadata or optional TLV are both fine as long as the space is e= nough and the detailed format can be defined and extended later. Thanks Lin From: Abilash Menon [mailto:amenon@128technology.com] Sent: Tuesday, January 10, 2017 10:47 AM To: Lin Han Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network Lin, Thanks. What is the signaling information carrying though. I think you are = alluding to some kind of metadata/header that QUIC can carry which is publi= c ? I did not quite understand your use case though. Another option would = be to have an optional tlv after the public headers where application can a= dd any app specific data. The Type would need further discussion though. T= his could be signaling, identifier or anything for the network elements - a= network element header. Jana, It looks like there is sufficient interest for sending information to the n= etwork elements via the QUIC packet. There may be multiple use cases and we= can probably work towards a consensus by not violating any of the chart go= als. Can we discuss this during some upcoming meeting with the interested p= arties. All, Please let us know if there are others who are interested in the network el= ements being QUIC aware. We could probably work together to discuss use cas= es and have a more in-depth technical discussion with Jana and others. Thanks, Abilash On Jan 10, 2017, at 1:32 PM, Lin Han > wrote: Hi, What I meant is the capability that QUIC can carry the signaling informatio= n distributed for the network device on the path, the signaling information= will be intercepted at each hop when the QUIC packets are forwarded. The d= etailed signaling can be designed later by other RFC. As for how the networ= k device knows to start looking for QUIC is another topic which should rely= on the IP packet, and QUIC cannot do anything. Thanks Lin From: Abilash Menon [mailto:amenon@128technology.com] Sent: Monday, January 09, 2017 2:05 PM To: Lin Han Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network Lin, We had suggested priority and streamed as a starting point to get more netw= ork aware details from the application. When you say signaling - are you in= dicating signaling to setup the network elements to start looking for QUIC = packets or for something else. Please clarify. Thanks, Abilash On Jan 9, 2017, at 3:15 PM, Lin Han > wrote: Hi, Abilash I have a question which might be related to this topic. >From the point of view of network device, we want to know and also wish tha= t the QUIC could support the signaling for the network device along the pat= h. This is for the QoS enhancement consideration in the future. Marking priori= ty is not enough for provisioning a device. The lesson from TCP is its rigidity for the extension. It would be nice tha= t QUIC has such elastic from the beginning of the design. Thanks Lin From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Abilash Menon Sent: Friday, January 06, 2017 5:17 AM To: Jana Iyengar Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG Subject: Re: soliciting feedback on draft-abilash-quic-network Jana, Thank you for reviewing. Please see inline : On Jan 5, 2017, at 10:52 PM, Jana Iyengar > wrote: Hi, Thanks for writing up the draft -- as Patrick notes, it's helpful to have s= omething concrete to discuss. I have a number of thoughts as I catch up on this thread, but I have a high= -order one: have you considered proposing this draft for HTTP/2? Given that= the use of streams is basically the same for HTTP/2 and HTTP over QUIC, I = would expect that signaling stream IDs and priorities for HTTP/2 should be = similar. Why not propose it for HTTP/2? We did not consider that, but we certainly could. Thank you for the suggest= ion. There are a significant number of engineering issues with doing priorities = per stream, the most significant one being the one that Christian points ou= t: that congestion control and loss detection will need to be per-stream, d= efeating a major rationale for stream multiplexing. That is a show-stopper,= in my opinion. You'd have the same troubles with TCP and HTTP/2. So if you consider packet pacing with multiple streams, the latency of one = stream need not be affected by another if one specific stream gets affected= . Yes this would need per stream congestion control - it looks like you don= e want to have that granular control here. So is there any network assistan= ce you would like the protocol to get if the network elements can support i= t. If so , please let us know - we would like to understand. I don't think prioritizing streams by network elements makes good engineeri= ng sense. Prioritization could certainly help streams. That could use the RFC7657 whi= ch Ted had mentioned, but our approach was to leverage the QUIC protocol it= self to use priority and get more granular view of the network using stream= ids. We will see if we can get some useful results. Thanks, Abilash - jana On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie > wrote: Reply in-line. On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon > wrote: Hey Ted, Thanks for your feedback. Please see replies inline : On Jan 5, 2017, at 2:57 PM, Ted Hardie > wrote: Howdy, Forgive the top posting, but this seems to be a bit of meta-question. If I= read your draft correctly, you are suggesting that QUIC expose stream iden= tifiers and associate them with a priority, so that on-path devices may mov= e certain streams onto higher priority paths or otherwise give variable qua= lity of service. That is one use case yes. The on-path devices can provide quality of servic= es on a per stream basis. For this to work correctly, though, the basic aim of multiplexing seems to = be changed as you could not multiplex streams into the same packet, even if= they have the same desired network treatment. At that level of isolation,= independent QUIC connections may suit your use cases just as well (if, ind= eed, you would choose QUIC at all). If that is the required level of indep= endence, why does opening different connections not work as well? Using stream1, the connection gets established and the headers get exchange= d using stream 3. Opening multiple connections would incur more latency for= the connection setup. So with one QUIC connection, multiple streams can le= verage the same connection without taking the hit of the connection establi= shment latency for each stream. With 0RTT, this is probably not an issue for a long-lived flows, and it has= to be compared to the cost for application mechanics to make sure that eac= h packet contains elements from only a single stream. For a multiplexing p= rotocol, the latter seems fundamentally sub-optimal. It's also not clear why you need that level of independence. At the very le= ast, your description makes it seem that you could multiplex streams whose = desired network treatment is the same. And, if you did multiplex streams w= ith the same desired network treatment, there seems to be no need at all to= expose the stream identifiers (after all, you might have more than one str= eam in a packet). Stream id being exposed would help build QUIC state machine in the network = elements for each stream as mentioned in the draft. The packet pacing mecha= nism will also benefit from this as it can be done a per stream basis and n= ot for the whole connection. So, "building the QUIC state machine in the network elements" doesn't mean = much absent a knowledge of what those network elements are going to do with= the state. The use case that you mentioned originally, path selection for= network treatment, doesn't actually require that the on-path elements dist= inguish among streams that require like treatment. It simply requires that= the requested network treatment be visible. Given that multiplexing strea= ms that require like network treatment works with the multiplexed design of= QUIC, I'm still unclear why you want to insist on such a strict independen= ce. Instead, you would only need to expose the desired network treatment for = a specific packet. Why is that not enough to meet the need and why, if tha= t is the case, would differentiated DSCP markings not meet your needs? Yes. Network treatment of a packet (priority) is definitely needed. Stream = id being exposed would help build QUIC state machine in the network element= s for each stream as mentioned in the draft. The packet pacing mechanism wi= ll also benefit from this as it can be done a per stream basis and not for = the whole connection. Your draft says this: However, session aware routers will have a flow per stream. Hence the packet rate can be adjusted on a per stream basis and not for the whole connection. Once again, this seems to run counter to the design of a multiplexed protoc= ol, and the description in the document is a bit circular. A session aware= router certainly would not have a flow per stream as QUIC is designed now;= it would have no way to create such a flow. You are motivating the change= in QUIC in order to achieve that for session aware routers, but without ad= dressing the loss of other basic QUIC design features. Also, the stream priority would be used to send among multiple paths in mul= ti path case. On the latter case, there was good bit of discussion on how well multiple D= SCP markings on a single 5-tuple would work in the context of WEBRTC; if yo= u have not read RFC 7657, I would suggest doing so, along with draft-ietf-t= svwg-rtcweb-qos. DSCP may not always guarantee the quality of service as it could be remarke= d by the routers in between. It also depends on other factors within the ro= uter eg: burst, packet rate etc . So the application priority can get lost= . Based on the QUIC stream priority, network elements could remark the DSC= P value to take a better path. So, I recommended you look at the document because it treats the problem of= having a single five(or six)-tuple flow have different markings. Evidentl= y, your basic answer is to replace the current flow-state management with a= different view of the flow ("session"), using the stream id as a demultipl= exing signal. You then wish to have a marking for the session. One of the design goals of QUIC is that it be deployable on the Internet as= it exists, rather than relying on features which must be introduced into t= he network to support it. This effort seems to run counter to that design = goal as well. We are not proposing any remarking of the QUIC stream priority, but that it= will remain the same. We can add authentication to make sure the fields ar= e in tact. Also in DSCP case a single flow will usually be given the same p= riority. In this case, the single flow/session can be given different prior= ities on a per stream basis. Of course, there is a potential silly state here if the session-state aware= network elements do something on one signal and their non-session-state pe= ers act on a different signal; at best, you'd have to scrub and re-mark to = avoid that. Given that, I fail to see why the multiple-markings within a f= low approach of RFC 7657 doesn't work at least as well, at least for the In= ternet as currently deployed. regards, Ted Thanks, Abilash Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect = many of the lessons learned would apply to your efforts, whether you used D= SCP or a different marking. regards, Ted On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee > wrote: Hi Team, We recently published draft-abilash-quic-network-00 which proposes a change= to the QUIC protocol header that will allow network elements to prioritize= streams in QUIC packets, divert high priority streams to low loss paths, a= nd adjust packet pacing on a per stream basis. We have already received som= e very positive comments from some members but wanted to solicit feedback f= rom the larger community. Please provide your comments/feedback/recommendat= ions as necessary: URL: https://www.ietf.org/internet-drafts/draft-abilash-quic-net= work-00.txt Htmlized: https://tools.ietf.org/html/draft-abilash-quic-network-00 Thank you in advance! Ritesh --_000_1D30AF33624CDD4A99E8C395069A2A162B86F986dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

The signaling information= is some QoS related information for the device programming. Metadata or op= tional TLV are both fine as long as the space is enough and the detailed format can be defined and extended later.

 <= /p>

Thanks<= /p>

 <= /p>

Lin

 <= /p>

 <= /p>

From: Abilash = Menon [mailto:amenon@128technology.com]
Sent: Tuesday, January 10, 2017 10:47 AM
To: Lin Han
Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on draft-abilash-quic-network<= /o:p>

 

Lin,

 

Thanks. What is the signaling information carrying t= hough. I think you are alluding to some kind of metadata/header that QUIC c= an carry which is public ?  I did not quite understand your use case t= hough. Another option would be to have an optional tlv after the public headers where application can add any app= specific data.  The Type would need further discussion though. This c= ould be signaling, identifier or anything for the network elements - a netw= ork element header. 

 

Jana,

 

It looks like there is sufficient interest for sendi= ng information to the network elements via the QUIC packet. There may be mu= ltiple use cases and we can probably work towards a consensus by not violat= ing any of the chart goals. Can we discuss this during some upcoming meeting with the interested parties.&nbs= p;

 

All,

 

Please let us know if there are others who are inter= ested in the network elements being QUIC aware. We could probably work toge= ther to discuss use cases and have a more in-depth technical discussion wit= h Jana and others.

 

Thanks,

Abilash

 

On Jan 10, 2017, at 1:32 PM, Lin Han <Lin.Han@huawei.com> wrote:

 

Hi,

 <= /p>

What I meant is the capab= ility that QUIC can carry the signaling information distributed for the net= work device on the path, the signaling information will be intercepted at each hop when the QUIC packets are forwarded. The detail= ed signaling can be designed later by other RFC. As for how the network dev= ice knows to start looking for QUIC is another topic which should rely on t= he IP packet, and QUIC cannot do anything.

 <= /p>

Thanks<= /p>

 <= /p>

Lin

 <= /p>

From: Abilash Menon [mailto:amenon@128techno= logy.com] 
Sent: Monday, Janu= ary 09, 2017 2:05 PM
To: Lin Han
Cc: Jana Iyengar; = Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: solic= iting feedback on draft-abilash-quic-network

 

Lin,

 

We had suggested priority and streamed as a starting= point to get more network aware details from the application. When you say= signaling - are you indicating signaling to setup the network elements to = start looking for QUIC packets or for something else. Please clarify.

 

Thanks,

Abilash

 

On Jan 9, 2017, at 3:15 PM, Lin Han <Lin.Han@huawei.com> wrote:

 

Hi, Abilash

 <= /p>

I have a question which m= ight be related to this topic.

 <= /p>

From the point of view of= network device, we want to know and also wish that the QUIC could support = the signaling for the network device along the path.

This is for the QoS enhan= cement consideration in the future. Marking priority is not enough for prov= isioning a device.

The lesson from TCP is it= s rigidity for the extension. It would be nice that QUIC has such elastic f= rom the beginning of the design.

 <= /p>

Thanks<= /p>

 <= /p>

Lin

 <= /p>

From: QUIC [mai= lto:quic-bounces@ietf.org]=  On Behalf Of Abilash Menon
Sent: Friday, Janu= ary 06, 2017 5:17 AM
To: Jana Iyengar Cc: Ritesh Mukherj= ee; Ted Hardie; IETF QUIC WG
Subject: Re: solic= iting feedback on draft-abilash-quic-network

 

Jana,

 

Thank you for reviewing. Please see inline :

 

On Jan 5, 2017, at 10:52 PM, Jana Iyengar <jri@google.com> wrote:

 

Hi,

 

Thanks for writing up the draft -- as Patrick notes,= it's helpful to have something concrete to discuss.

 

I have a number of thoughts as I catch up on this th= read, but I have a high-order one: have you considered proposing this draft= for HTTP/2? Given that the use of streams is basically the same for HTTP/2= and HTTP over QUIC, I would expect that signaling stream IDs and priorities for HTTP/2 should be similar. Why= not propose it for HTTP/2?

 

We did not consider that, but we certainly could. Th= ank you for the suggestion.





 

There are a significant number of engineering issues= with doing priorities per stream, the most significant one being the one t= hat Christian points out: that congestion control and loss detection will n= eed to be per-stream, defeating a major rationale for stream multiplexing. That is a show-stopper, in my opi= nion. You'd have the same troubles with TCP and HTTP/2.

 

So if you consider packet pacing with multiple strea= ms, the latency of one stream need not be affected by another if one specif= ic stream gets affected. Yes this would need per stream congestion control = - it looks like you done want to have that granular control here. So is there any network assistance you would l= ike the protocol to get if the network elements can support it. If so , ple= ase let us know - we would like to understand. 





 

I don't think prioritizing streams by network elemen= ts makes good engineering sense.

 

Prioritization could certainly help streams. That co= uld use the RFC7657 which Ted had mentioned, but our approach was to levera= ge the QUIC protocol itself to use priority and get more granular view of t= he network using stream ids. We will see if we can get some useful results.

 

Thanks,

Abilash

 





 

- jana

 

 

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Reply in-line.

 

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <amenon@128technology.com> wrote:

Hey Ted,

 

Thanks for your feedback. Please see replies inline = :

 

On Jan 5, 2017, at 2:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

 

Howdy,

Forgive the top posting, but this seems to be a bit = of meta-question.  If I read your draft correctly, you are suggesting = that QUIC expose stream identifiers and associate them with a priority, so = that on-path devices may move certain streams onto higher priority paths or otherwise give variable quality of service.<= o:p>

 

That is one use case yes. The on-path devices can pr= ovide quality of services on a per stream basis. 





 

For this to work correctly, though, the basic aim of= multiplexing seems to be changed as you could not multiplex streams into t= he same packet, even if they have the same desired network treatment. = At that level of isolation, independent QUIC connections may suit your use cases just as well (if, indeed, you wou= ld choose QUIC at all).  If that is the required level of independence= , why does opening different connections not work as well?

 

Using stream1, the connection gets established and t= he headers get exchanged using stream 3. Opening multiple connections would= incur more latency for the connection setup. So with one QUIC connection, = multiple streams can leverage the same connection without taking the hit of the connection establishment lat= ency for each stream.

 

With 0RTT, this is probably not an issue for a long-= lived flows, and it has to be compared to the cost for application mechanic= s to make sure that each packet contains elements from only a single stream= .  For a multiplexing protocol, the latter seems fundamentally sub-optimal.

 






It's also not clear why you need that level of independence. At the very le= ast, your description makes it seem that you could multiplex streams whose = desired network treatment is the same.  And, if you did multiplex stre= ams with the same desired network treatment, there seems to be no need at all to expose the stream identifiers (after a= ll, you might have more than one stream in a packet).

 

Stream id being exposed would help build QUIC state = machine in the network elements for each stream as mentioned in the draft. = The packet pacing mechanism will also benefit from this as it can be done a= per stream basis and not for the whole connection. 

 

 

So, "building the QUIC state machine in the net= work elements" doesn't mean much absent a knowledge of what those netw= ork elements are going to do with the state.  The use case that you me= ntioned originally, path selection for network treatment, doesn't actually require that the on-path elements distinguish among strea= ms that require like treatment.  It simply requires that the requested= network treatment be visible.  Given that multiplexing streams that r= equire like network treatment works with the multiplexed design of QUIC, I'm still unclear why you want to insist on su= ch a strict independence.

 

  Instead, you would only need to expose the de= sired network treatment for a specific packet.  Why is that not enough= to meet the need and why, if that is the case, would differentiated DSCP m= arkings not meet your needs?

 

Yes. Network treatment of a packet (priority) is def= initely needed. Stream id being exposed would help build QUIC state machine= in the network elements for each stream as mentioned in the draft. The pac= ket pacing mechanism will also benefit from this as it can be done a per stream basis and not for the whole conne= ction.

 

Your draft says this:= 

   However, session aware routers will have a flow per<=
/o:p>
   stream.  Hence the packet rate can be adjusted on a =
per stream basis
   and not for the whole connection.

Once again, this seems to run counter to the design = of a multiplexed protocol, and the description in the document is a bit cir= cular.  A session aware router certainly would not have a flow per str= eam as QUIC is designed now; it would have no way to create such a flow.  You are motivating the change in QUIC = in order to achieve that for session aware routers, but without addressing = the loss of other basic QUIC design features.

 

Also, the stream priority would be used to send amon= g multiple paths in multi path case. 

 


 

 

On the latter case, there was good bit of discussion= on how well multiple DSCP markings on a single 5-tuple would work in the c= ontext of WEBRTC; if you have not read RFC 7657, I would suggest doing so, = along with draft-ietf-tsvwg-rtcweb-qos. 

 

DSCP may not always guarantee the quality of service= as it could be remarked by the routers in between. It also depends on othe= r factors within the router eg: burst,  packet rate etc . So the appli= cation priority can get lost.  Based on the QUIC stream priority, network elements could remark the DSCP value to = take a better path.

 

So, I recommended you= look at the document because it treats the problem of having a single five= (or six)-tuple flow have different markings.  Evidently, your basic an= swer is to replace the current flow-state management with a different view of the flow ("session"), using = the stream id as a demultiplexing signal.  You then wish to have a mar= king for the session. 

One of the design goals of QUIC is that it be deploy= able on the Internet as it exists, rather than relying on features which mu= st be introduced into the network to support it.  This effort seems to= run counter to that design goal as well.

 

We are not proposing any remarking of the QUIC strea= m priority, but that it will remain the same. We can add authentication to = make sure the fields are in tact. Also in DSCP case a single flow will usua= lly be given the same priority. In this case, the single flow/session can be given different priorities on a = per stream basis.

 

 

Of course, there is a= potential silly state here if the session-state aware network elements do = something on one signal and their non-session-state peers act on a differen= t signal; at best, you'd have to scrub and re-mark to avoid that.  Given that, I fail to see why the multipl= e-markings within a flow approach of RFC 7657 doesn't work at least as well= , at least for the Internet as currently deployed.

regards,

Ted

 

Thanks,

Abilash

 

 

Though pointing primarily at RTP flows multiplexed u= sing BUNDLE, I suspect many of the lessons learned would apply to your effo= rts, whether you used DSCP or a different marking.

 

regards,

Ted

 

 

On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee <= ;rmukherjee@128technology.com> wrote:

Hi Team,

 

We recently published draft-abilash-quic-network-00 which proposes a c= hange to the QUIC protocol header that will allow network elements to prior= itize streams in QUIC packets, divert high priority streams to low loss paths, and adjust packet pacing on a per stream basis.= We have already received some very positive comments from some members but= wanted to solicit feedback from the larger community. Please provide your = comments/feedback/recommendations as necessary: 

 

URL:            https://www.ietf.org/internet-drafts/draft-abilas= h-quic-network-00.txt

Htmlized:       https://tool= s.ietf.org/html/draft-abilash-quic-network-00

 

Thank you in advance!

 

Ritesh

 

--_000_1D30AF33624CDD4A99E8C395069A2A162B86F986dfweml501mbb_-- From nobody Tue Jan 10 11:43:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3DE129850 for ; Tue, 10 Jan 2017 11:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 TjVn5lkHdAzw for ; Tue, 10 Jan 2017 11:43:28 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC9612984A for ; Tue, 10 Jan 2017 11:43:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,344,1477983600"; d="scan'208";a="163963193" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 10 Jan 2017 11:37:25 -0800 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 10 Jan 2017 11:42:12 -0800 Received: from NAM03-BY2-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.1210.3 via Frontend Transport; Tue, 10 Jan 2017 11:42:11 -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=vaIntcSdHlAstiutea9zMPXkghIT0rh91/Q9oJUQzi8=; b=Byv39Zb+9ISm8wITezAU3ja69Hlk/U/TJRRY40xdF93z6eFkV4kq0lFVlAjw5i7HMvnTYlmvxRCd97YABc1ux+qMMr15IdH1wlY/3O9y3PX08ZYcTnPVXjV4GeJZ0DZ20LSRPvLuKQjk2mH3SxLOiDv0+4/qVR+fAaCPq2MWoCU= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 10 Jan 2017 19:42:11 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0803.021; Tue, 10 Jan 2017 19:42:11 +0000 From: "Eggert, Lars" To: Abilash Menon Subject: Re: soliciting feedback on draft-abilash-quic-network Thread-Topic: soliciting feedback on draft-abilash-quic-network Thread-Index: AdJnaJAo7EFh+AryQuCJjvpLcGn68QAJVUAAAAe3JoAAARIvgAAH0h6AABO0C4AApX1YAAAD1f0AACrhrwAAAIFYAAAB6OiA Date: Tue, 10 Jan 2017 19:42:10 +0000 Message-ID: References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F92A@dfweml501-mbb> <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> In-Reply-To: <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:31bd:e101:1c84:e21:24a7:d44] x-ms-office365-filtering-correlation-id: f99fa6cb-1cb3-4acd-f902-08d43990c51d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1156; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:yMmX4YmtGOCdv6FCXKb7QZNdZqYJFU52wn/3A8ASsbQKVev7BfJKEkNWD1bZngMWrTocO1aLbWGizxzg/hVVk8lvvfxnnqlEJDTLNplpx4asDHSKNiTpmDlHYgWbeyxkrs9HQ7NVS+ics71mWvZcpzFCbtQ7E7wdJGOBap8QrSHiL8P1YYBU+fVLWLuXEcHo+SGrjhriaezuTnw78dZ7IcHfp6HTeo2D1f5WLNJQ7j+9qXUwbqqMijrmRcEStjHQHejIDI3wbVZwQiAQFe1wM7je9MTGYW+kqjRCn4oZ2wINtUjatq72OqOAkYG7qsGVPzLlqIuEslEFWbzxZklt5OFDF+scTKKwrBBddHhTrQwA9SE3qf6ONG0CflzgFm7h58aQwLMrUGOwa5DmpS0ADEdBf9+PfTWwR5gXi/agnYlLREGHoAijhuITRnmeM1Fl+TE1jZA8B5QAMiGQHmAI+Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(377424004)(24454002)(6436002)(106356001)(8936002)(82746002)(38730400001)(50226002)(83716003)(8676002)(6506006)(39060400001)(81166006)(81156014)(105586002)(3280700002)(4326007)(68736007)(36756003)(229853002)(2906002)(86362001)(6116002)(25786008)(3660700001)(57306001)(230783001)(305945005)(5660300001)(99286003)(33656002)(2900100001)(102836003)(50986999)(4001150100001)(101416001)(110136003)(122556002)(6486002)(97736004)(77096006)(6916009)(2950100002)(54906002)(93886004)(189998001)(6512007)(92566002)(76176999)(7736002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.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: text/plain; charset="us-ascii" Content-ID: <71DDC4BFA667F443A5C9172A3D7CC5A5@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 19:42:10.9971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: Cc: Ritesh Mukherjee , Jana Iyengar , Ted Hardie , IETF QUIC WG , Lin Han X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Jan 2017 19:43:35 -0000 Hi, On 2017-1-10, at 19:47, Abilash Menon wrote: > It looks like there is sufficient interest for sending information to the= network elements via the QUIC packet. There may be multiple use cases and = we can probably work towards a consensus by not violating any of the chart = goals. Can we discuss this during some upcoming meeting with the interested= parties.=20 there may be interest, but my reading of the charter - as chair - is in lin= e with Ian's and Jana's. "Sending information to the network elements via t= he QUIC packet", if such information includes elements not currently expose= d by H2 over TLS, is outside the scope of our current charter. > All, >=20 > Please let us know if there are others who are interested in the network = elements being QUIC aware. We could probably work together to discuss use c= ases and have a more in-depth technical discussion with Jana and others. This topic can certainly be discussed amongst interested parties. I would l= ike to ask the WG to prioritize work on our currently chartered milestones,= however. Thanks, Lars= From nobody Tue Jan 10 12:01: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 7FE7B129859 for ; Tue, 10 Jan 2017 12:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 If6-4RbnwDSH for ; Tue, 10 Jan 2017 12:01:54 -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 65244129D81 for ; Tue, 10 Jan 2017 12:01:21 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id 137so366939292vkl.0 for ; Tue, 10 Jan 2017 12:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PCKybh5kc6P+4Dwugc8VveMj4Q7snWCLOqCKHnAXlg0=; b=Tx/Ndj5CD4LLIVPd/u6H2s+zmnNr62BVrsLEWFJ8zOYcmUlSXbtskVsE0jW4mVtJsw 2RhwWqTebmUn3i3OnYtvH79jW1ho4Nf0VDCAUJsOLKEIHyjoTRQfzrGbelHbegkOQ5yT 7J07z2Y3Te1zi/dDVWQLbv4CPFG8BLm0R+X5UIMSVmjWjw1lxYfD0ZIHN0nRVPXUqegj LJBm8KwUy4BrzClZAx4StnttNHCeLv3qdLbclhzq+1m+vRcYm9rKU7z89fcDGdoM6Xzj 0fOO7urC2OuqbbX2LLwZ6UfmAMvzbYAiXQpai7VmXUY+sOZxX8RXHEMnSfDFgjqTAP6Q RVaQ== 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=PCKybh5kc6P+4Dwugc8VveMj4Q7snWCLOqCKHnAXlg0=; b=aM8foDVFZnFf/rT52Cd2OAa0ZkGz+KsAN+iE2ZUuoaILbgFG+yp48sLpv2zIwvmT5o C03HbLWOmY6AWMTykE8kP/0KfQt9CnmV8TwgAZUH8A+81tV7pukDZ0NY3otCc+PWuX72 yXN60M5ndfOCN41CfKtYgGMLRr5JXPKE/yvH8flDnMGexf4eElAesgGf+ajVZq0lporS tFr6atumotChGuee6OpLFbhw5zFdieGOFN/uAFVGRMtgOAWxI/E/Vd1TV/0i+bqxjc7j MzXKT5yNo02vphj8aK6GFOxfthZyCWO2+hLiP7OxvhGQg4JQwACTmIHNWlILDFRdbWdC 3Mlw== X-Gm-Message-State: AIkVDXLbSmlyVYbNEpxcqJ1CM5M1xBk/Zzn8jPM/pjmMeeFfSipaJNEuhwL8oTQfrdDHQzuiIIhq8PZOaJU/nKcN X-Received: by 10.31.99.134 with SMTP id x128mr2252950vkb.161.1484078480240; Tue, 10 Jan 2017 12:01:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 10 Jan 2017 12:01:19 -0800 (PST) In-Reply-To: <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F92A@dfweml501-mbb> <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> From: Jana Iyengar Date: Tue, 10 Jan 2017 12:01:19 -0800 Message-ID: Subject: Re: soliciting feedback on draft-abilash-quic-network To: Abilash Menon Content-Type: multipart/alternative; boundary=94eb2c07cff8a2aa450545c2f207 Archived-At: Cc: Ritesh Mukherjee , Ted Hardie , IETF QUIC WG , Lin Han X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Jan 2017 20:01:55 -0000 --94eb2c07cff8a2aa450545c2f207 Content-Type: text/plain; charset=UTF-8 Hi Abhilash, > It looks like there is sufficient interest for sending information to the > network elements via the QUIC packet. There may be multiple use cases and > we can probably work towards a consensus by not violating any of the chart > goals. Can we discuss this during some upcoming meeting with the interested > parties. > There's always been interest in sending information to network elements via any/all packets, not just QUIC ones. The prevalence of information exposure has led us to this juncture where middleboxes have ossified transport evolution almost completely. Going forward, we have to assume that anything that is exposed to the network will be ossified for life, and so the bar for exposing any information is quite high. The information that this proposal asks for is pretty deep information, and and the justification does not meet the bar. IMO, I don't think there's any rationale that can meet the bar for exposing stream IDs. There are too many flawed assumptions about what stream IDs mean for a design that uses it in-network to make any sense. To be clear, please do not engineering a solution before you can convincingly argue for the existence of the problem and the sanity of the solution space. I'm not convinced of either. - jana --94eb2c07cff8a2aa450545c2f207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi A= bhilash,
=C2=A0
I= t looks like there is sufficient interest for sending information to the ne= twork elements via the QUIC packet. There may be multiple use cases and we = can probably work towards a consensus by not violating any of the chart goa= ls. Can we discuss this during some upcoming meeting with the interested pa= rties.=C2=A0

There's always= been interest in sending information to network elements via any/all packe= ts, not just QUIC ones. The prevalence of information exposure has led us t= o this juncture where middleboxes have ossified transport evolution almost = completely. Going forward, we have to assume that anything that is exposed = to the network will be ossified for life, and so the bar for exposing any i= nformation is quite high. The information that this proposal asks for is pr= etty deep information, and and the justification does not meet the bar. IMO= , I don't think there's any rationale that can meet the bar for exp= osing stream IDs. There are too many flawed assumptions about what stream I= Ds mean for a design that uses it in-network to make any sense.
<= br>
To be clear, please do not engineering a solution before you = can convincingly argue for the existence of the problem and the sanity of t= he solution space. I'm not convinced of either.

- jana
=C2=A0
--94eb2c07cff8a2aa450545c2f207-- From nobody Tue Jan 10 23:46: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 9484F129A62 for ; Tue, 10 Jan 2017 23:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPTUbAaR5ojf for ; Tue, 10 Jan 2017 23:46:45 -0800 (PST) Received: from trammell.ch (unknown [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C5333129A58 for ; Tue, 10 Jan 2017 23:46:44 -0800 (PST) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id B428F1A01CD; Wed, 11 Jan 2017 08:46:12 +0100 (CET) Subject: Re: soliciting feedback on draft-abilash-quic-network Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4D6F2B16-3932-4D45-8E50-AEEAAC6DBA8A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Wed, 11 Jan 2017 08:46:11 +0100 Message-Id: <06F6F4C6-1354-48AD-B3A9-15423570E922@trammell.ch> References: <021d01d26769$3b8c1970$b2a44c50$@128technology.com> <5FACC824-F376-4EBB-8C10-6422A12013C1@128technology.com> <9CDA2246-4C10-4C1F-BCCA-BB8E4776F71C@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F57C@dfweml501-mbb> <4330DB1C-AFEB-4EF0-ACA2-95ABF572807E@128technology.com> <1D30AF33624CDD4A99E8C395069A2A162B86F92A@dfweml501-mbb> <0D9E797B-2E56-4C97-BC5C-4BC5796EE152@128technology.com> To: Abilash Menon , Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ritesh Mukherjee , Ted Hardie , IETF QUIC WG , Lin Han X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Jan 2017 07:46:46 -0000 --Apple-Mail=_4D6F2B16-3932-4D45-8E50-AEEAAC6DBA8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, Abilash, all, > On 10 Jan 2017, at 21:01, Jana Iyengar wrote: > There are too many flawed assumptions about what stream IDs mean for a = design that uses it in-network to make any sense. This is a very important point, and I want to quote it for emphasis. Stream identifiers in QUIC (as in HTTP/2) are essentially = application-level semantic entities. There is no reason for anything = other than the endpoints to know anything about them. Existing efforts to build in-network functionality have tended to assign = properties to flows, and to provide whatever treatment that = functionality requires keyed on flow. This isn't really a design feature = of the current Internet architecture, it's simply a historical accident. = Most of the traffic on most networks is TCP, and TCP is widely assumed = to be intolerant of packet reordering. Any attempt to deliver TCP = traffic without reordering therefore means you need to treat packets = with the same five- (or six-, including DSCP, on networks where it = works) tuples the same, and that gives you a natural way to group = packets, and to hang other functionality off those groups. > To be clear, please do not engineering a solution before you can = convincingly argue for the existence of the problem and the sanity of = the solution space. I'm not convinced of either. (hi Jana, I'm going to ignore this bit of advice for a moment -- sorry! = -- because there does exist an obvious less-insane subset of the = solution space for grouping QUIC packets for network treatment than = stream exposure. I will leave the argument for the existence of the = problem aside at the moment, as well as the messier problems of = expressing desired network treatment in network-level semantics.) Stream identity doesn't carry any information about desired or desirable = network treatment of a given packet. Any network treatment information = must therefore necessarily be inferred. Implicit assumptions about = packet treatment by on-path devices are a large part of how we got into = the mess we're in with respect to network manageability in the first = place. But even assuming that an application wants to segregate its = packets by groups that require different treatment by the network = (canonical example, WebRTC channels with different DSCP codepoints), = streams aren't the way to do that. In QUIC, if an application determines = that different parts of a connection really do need to be = distinguishable in the network, we could use existing identifiers = already exposed to the network: the five-tuple. Adding a five-tuple to an existing connection in QUIC is theoretically = extremely cheap: just pick a port and send a packet. Of course, running = a single connection ID over multiple simultaneous five-tuples is not yet = supported by the protocol as specified, but since it's just a = generalization of the rebinding case, it's (1) much easier to do in = terms of engineering effort, since it doesn't break as many existing = assumptions, as well as (2) far less odious for its exposure of = undesired information about the application layer semantics than stream = ID exposure. Cheers, Brian --Apple-Mail=_4D6F2B16-3932-4D45-8E50-AEEAAC6DBA8A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYdeLEAAoJEIoSt78L6kajaPwP/j0Ukv1zjVTF8dynX9HX9vH2 Wc5htj9u7PuWM0sfhBWgps/XgqVLh2KR7Dg4BT/GS9jvF1dcxPaPf71Pnz66sxbK IIghwX5sHY/eOGcwCCkJobve+DSAECBj7QaUajEG7dqXBXJFvZHkZ+fsNBudRJeD i+FdYJuC1IHq7QS62RmEBcOrp9GWnhLeeWIGBOH0Q6H4t/Dt+ivbFFh1aN8wP8iw Qd/SDjabK3+K8OhYMNzA6Tsjaj1h4lEmej4lB6UsqxN8NOECNxCkDd/8Gkd/lZ1n PAUeehfkp8Vs+oFuOpE03WWDrvbPi3RhvG8WOBGXL8tlQYbs5E6764lhJNvmnni3 ZH4YlF4UMNfRPWV44+d6dIyKuHGW34MzzN1j9UmbsaMbTlXy5XZsjH1ppwxEFOPP PeqXqkQFLA9HQIVx1UbWRjnceTpSnpHRn++2Na2TLLEs8l5IDiX0NdWr/UgvvoXG j7H4pRpFKruO9MGM50l2KwsUWAty4D5uUn8YpgpbQ4HYofoNlU7E5sKUt/V8Ox5J lYQWIcH0W0eItnIMUMrKQkGv94QjJk83k9racbM0YXsh8p+dFIcIqLZuOcbBI4nL 5jY4kxiBBkMwQTKVih8OZ9b8gbLZLHVW86kerqc6zm2d9QaSEfjXmmGjlIu4tOx3 9VFnL5dbOhCE4eSe7TH/ =J4b6 -----END PGP SIGNATURE----- --Apple-Mail=_4D6F2B16-3932-4D45-8E50-AEEAAC6DBA8A-- From nobody Wed Jan 11 00:23: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 7DEC0129A91 for ; Wed, 11 Jan 2017 00:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 I1uct4TUCuS8 for ; Wed, 11 Jan 2017 00:23:12 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56569129A92 for ; Wed, 11 Jan 2017 00:23:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,345,1477983600"; d="scan'208";a="168623329" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 11 Jan 2017 00:13:14 -0800 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 11 Jan 2017 00:18:10 -0800 Received: from NAM03-DM3-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.1210.3 via Frontend Transport; Wed, 11 Jan 2017 00:18:10 -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=mFrX3u4zpLBR1cuAdLz6ay+zVmNPXTmYO3D4qhMqEw0=; b=LNDq2Q24d6s0C0ZbXlnuf2QIrn5ejfcu/llPSA/ksDU1EGWMKAb9mPqsUo21GqqSExfSvbsyiUTLgsNpVtILsCcsrpff4vnuDAxyianYriW7UdXraeppQeiNWDZZb3TBl8qvTW05rPeK7kxqLjYBzbw4nO31h+uvro/CaPjLLKk= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 11 Jan 2017 08:18:09 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0803.021; Wed, 11 Jan 2017 08:18:09 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Re: Confirming consensus on using big-endian Thread-Topic: Confirming consensus on using big-endian Thread-Index: AQHSW4mGzCwkS862HUmqjPU9smsw9aEzD2aA Date: Wed, 11 Jan 2017 08:18:09 +0000 Message-ID: <01D4EA9F-84D0-4419-842D-0661DEF549C5@netapp.com> References: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> In-Reply-To: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 12079d97-4ff6-4ea9-c410-08d439fa60af x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1156; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:IOCwxTYTxxViIA/deGDrOFa0CaSJMYF2RM6hTJiI5rrDQEELcdSwqECy729nV1Bevtcj2ZtztycMG93tWsGblmXFF8uVvfgTndyC53zMeyZFSKwNR2PzEKCT/XDRHqxFGfI4CUBQy4H60NyE+kWg2RY8Wr40/1Nwx0JSwbuRY/lbxPKHxRkQnjJs2nCvTXAxdFrWZFIlhcIGM20C/LsFy48+820nFbt7p9UQ3gQq12m9jNkxa8kAFbDxcFhMHsdb1fwLRUqLc4SOj+SsiZOw0QgPa8Zty6xtF4BNAg7oW7Hc62HMmR08U6oOeRMTGbBI5RgAw812zibjoU+jB8Ll43BBZr6mvXIce3zxabHlFBrM9EsnPLT1HhBI1zLO25MV5s/UOIbrBNklve3bJDJRbUR+Kc+DGJcoK2TWORWd0Endk8D677etBhjbGK8hGSSZsblQLxiVUALYBt98Q2WWHQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(377424004)(199003)(189002)(2900100001)(3846002)(102836003)(5660300001)(3660700001)(57306001)(99286003)(305945005)(450100001)(189998001)(7736002)(6512007)(2950100002)(6916009)(107886002)(76176999)(92566002)(101416001)(110136003)(4001150100001)(50986999)(77096006)(6486002)(122556002)(97736004)(6506006)(83716003)(8676002)(105586002)(33656002)(81156014)(81166006)(38730400001)(106356001)(8936002)(6436002)(82746002)(50226002)(66066001)(86362001)(25786008)(6116002)(106116001)(68736007)(229853002)(3280700002)(2906002)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 08:18:09.1880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:23:13 -0000 Hi, On 2016-12-21, at 13:55, Eggert, Lars wrote: > we had very strong consensus during the Seoul meeting to use big-endian e= ncoding for QUIC. We'd like to confirm this consensus on the list.=20 >=20 > If you *disagree*, please reply to the list by Jan 6, 2017. nobody disagreed with this during the consensus call, so the editors will m= ake this change. Lars= From nobody Wed Jan 11 00:28: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 48E2B129A91 for ; Wed, 11 Jan 2017 00:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 jhwyiUAGUgwq for ; Wed, 11 Jan 2017 00:28:27 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE24129A8D for ; Wed, 11 Jan 2017 00:28:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,345,1477983600"; d="scan'208";a="164115930" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx142-out.netapp.com with ESMTP; 11 Jan 2017 00:23:18 -0800 Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 11 Jan 2017 00:28:07 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 11 Jan 2017 00:28: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=hySGEtaScpIYMTy0HPqpnUiq6rhJX8KySQWVQjOBrRE=; b=NdfZUq1x0Mc+nfJn9NSxyNFZF9Q5JbFYHcAsgOLarjJ3oTUiBL1Rr1JUscZ/cZ0MvyDTh4rZIhbtZyz66s04NFT2gK3x+j9MFnozCZpjP6yaGpKDmaJE8J6hOn9pRmFEuA3E6NMiYL6HRDmG02tzs2kAfFrWZES/TaJxPmo6b8Q= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 11 Jan 2017 08:28:05 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0803.021; Wed, 11 Jan 2017 08:28:05 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Preparations for Tokyo interim Thread-Topic: Preparations for Tokyo interim Thread-Index: AQHSa+ShTe8fsk34vU6oxrn8mcJsww== Date: Wed, 11 Jan 2017 08:28:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 852f967d-e851-472a-1c47-08d439fbc406 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1154; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:8DxvQbRIDhforO6QAAJXi98uZ8a9sjEUHTBIcmloAHNIm4F5LgRLwwk5nyThwwK7xAHwKBwRRlBBt/pnN6P1S9zEDmDbUgJMic+6l6mQTR0yPgfrkRJ4Pf2lrv8LJsG9eNKxEWSV/JATyWdQfyLQCMEJ0S+Nau46xYuSgbqVgS0QAAL2m8PrlERZrcVMeItnxoo2AAWu+37CAnoFaNNm927VVX03y8unfleAv3Pjoo+MfRXLIJuR0ezvnPrTVQDX05bMaGS7c4PiA//P+sPxons89D433nRlD6t8dvd/EOfYkfkUJyLpOIyADe/bATYVjuZlKgn2II2Fzl+nKm+7pWQ9EKnERbINLFiXt2vsQvwWGxqWXXqdgKQ8wQiubrzHmaew+CweZGOuE9wPPqwXtl4JY8EdILtsMdQR+Q2UDi6t43ZJ6GS2rl6fv7qoWFxsXxBvcT221wKaE5JXRU2eig== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(46034005)(189002)(199003)(6506006)(66066001)(6116002)(102836003)(99286003)(3846002)(82746002)(106356001)(5660300001)(3280700002)(36756003)(77096006)(92566002)(6512007)(6306002)(83716003)(6486002)(106116001)(38730400001)(57306001)(6436002)(105586002)(7736002)(97736004)(122556002)(101416001)(189998001)(3660700001)(8676002)(2900100001)(81156014)(81166006)(110136003)(2906002)(33656002)(3480700004)(50226002)(25786008)(86362001)(450100001)(305945005)(8936002)(107886002)(68736007)(6916009)(50986999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.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: text/plain; charset="us-ascii" Content-ID: <86C213BE7BA08E4FBF39D2532C001E26@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 08:28:05.3341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:28:29 -0000 Hi, in preparation for our Tokyo interim (https://github.com/quicwg/wg-material= s/blob/master/interim-17-01/arrangements.md), here is what Mark and me woul= d like to see happen: *** By this weekend***, the editors should prepare and submit new revisions= of the core specs, and label issues in GitHub as follows: For any open issues where it is the editors' judgement that there is consen= sus emerging on a resolution, they should incorporate that into the ID revi= sions. Please label any such issues in GitHub (maybe with "confirm-consensu= s" or something similar.) For any open issues where it is the editors' judgment that more discussion = is needed to come to consensus on a resolution, they should NOT make any te= xtual changes to the new revisions. Please label any such issues in GitHub = (maybe with "needs-discussion" or something similar.) Once the new revisions are available, the WG - and especially the folks par= ticipating in the Tokyo interim - should review them and check them against= the labeled GitHub issues. Mark and me will use the issues to come up with= an agenda for Tokyo in the week prior to the interim, and post it for revi= ew. We expect to spend most of the time on "needs-discussion" issues and (time = permitting) new topics, and go through the "confirm-consensus" issues fairl= y rapidly. Finally, apologies for the rather short review time before the interim. The= holiday season had an effect on productivity. We'll strive to do this bett= er in the future. Lars (for the chairs)= From nobody Wed Jan 11 07:31: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 AA0B41294C5 for ; Wed, 11 Jan 2017 07:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t5h4We7fzGl for ; Wed, 11 Jan 2017 07:31:26 -0800 (PST) Received: from trammell.ch (unknown [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54E1294EC for ; Wed, 11 Jan 2017 07:31:26 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 1B1B21A052C for ; Wed, 11 Jan 2017 16:31:25 +0100 (CET) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_3B957A45-B75D-469A-BE67-B83D223C18B8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: How fiddly should the QUIC header be? Date: Wed, 11 Jan 2017 16:31:24 +0100 Message-Id: <234A0F1A-494D-4A1A-8A94-43550614A0B2@trammell.ch> To: IETF QUIC WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:31:28 -0000 --Apple-Mail=_3B957A45-B75D-469A-BE67-B83D223C18B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, This message concerns several running issues in GitHub, so I figured I'd = start the conversation the old fashioned way on the list. Happy to file = an issue and to make a PR happen if the outcome of this discussion isn't = a unanimous "please go away", though. Apologies for the length. Most of = it is ASCII art, which I hope is as fun to read as it was to draw ;) The -latest version of the QUIC transport draft defines seventeen = different possible headers for QUIC packets, ignoring the = diversification nonce, which remains under discussion but should in my = understanding adds only one additional possible header, and in any case = doesn't significantly impact the discussion here. The seventeen headers = appear in the appendix to this message. I note several potential issues with this arrangement, all of which = impact sender and receiver code complexity. Complexity, especially in = parsers (i.e., on the receiver side), is a source both of unclarity in = specifications and errors in implementation: (1) There are thirteen possible header lengths, and therefore data = offsets : 2, 3, 5, 6, 7, 9, 10, 11, 13, 14, 15, 17, 21. Each of the = header fields has a variety of possible offsets. This also increases the = complexity of hardware offload implementations of QUIC, but is not = complex enough to prevent their implementation and deployment. (2) There are combinations of flags that seem to be nonsensical and/or = contradictory (e.g., the Packet Number Length codepoint adds 1, 2, 4, or = 8 to the length if the Public Reset flag is clear, but 0 to the length = if the Public Reset flag is set, see ; Public Reset and Version are = mutually exclusive.) (3) There appears to be no consideration given to reducing confusability = with other deployed UDP protocols in the first N bytes of the header. = Admittedly, in a world where QUIC is limited to udp/443, this matters = much less than it may when other applications are adapted to run on top = of it. But given that the only invariants in the header are in the = definition of the version space and how to determine whether a version = number is present, I would suggest reducing the number of possible header layouts to reduce = complexity, based on the following observations and assumptions: (1) The set of variable header lengths will, at most, save a number of = bytes per packet that will often be lost in the underflow of suboptimal = path MTU discovery. (I think Martin Duke already made this point?) (2) Varlen packet numbering makes sense if the packet number always = starts from zero, but random initial packet numbers have other = advantages; I presume we'll adopt them at some point. Packet numbers = only need to be large enough to keep wrap-arounds to be induced by = reordering, so 32 bits (as in the TCP sequence number space) is more = than sufficient. (3) There is value in treating a version number as a magic number to = help reduce the chance of misrecognition of non-QUIC packets as initial = QUIC packets at an endpoint (e.g., those created by a reflection attack = against an existing UDP service). (4) Thirty-two bits of version are more than enough. 24 suffice. (I note = this will require a rethought of the version number space. This should = probably also play nicely with DNS/NTP reflection, other widely deployed = UDP protocols, and RFC 7983. I leave this to future work.) As an initial proposal, I would propose that either both Connection ID = and Version be present, or neither, and that packet number be always = present and constant length. This reduces the set of necessary flags to = three, leaving us with five flags for reserved/future use (four, if we = go ahead and allocate multipath) and the following two header layouts: Full Header: 16 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|R|K|M| zero | version/magic (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- Connection ID -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Truncated Header: 5 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|K|M| zero | Packet Number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | +-+-+-+-+-+-+-+-+ The header invariant then becomes "If bit 0x80 in octet 0 is 1, then the = seven remaining bits of that octet are reserved for use as flags, and = octets 1-3 are a 24-bit version number. If bit 0x80 in octet 0 is 0, = then no version number is present; use previous version information for = this 5-tuple." I note that this proposal is completely incompatible with the previous = header. But we already paid for a flag-day by switching endianness. It = makes sense to make full use of the flag day we've bought, in order to = make the header (especially the parts of it we can't change) less = fiddly. (I also personally think the truncated header is of little use; eleven = bytes don't cost much, we could get back a flags bit and some complexity = if we just said here's your sixteen octet header, enjoy. But this = proposal gives us some of the performance benefits of the fiddly header = without all the fiddling.) Cheers, Brian Appendix: Here are the seventeen headers I found. First, a set of conventions for the diargams. Let's name the flags: 0 =3D Reserved (always zero) M =3D Multipath (always zero) P =3D Packet number side C =3D Connection ID present K =3D Key phase R =3D public Reset V =3D Version present +-+-+-+-+-+-+-+-+ |0|M| P |C|K|R|V| +-+-+-+-+-+-+-+-+ Header 0: flags and packet number, 2 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 0|0|0|0|0| packet num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 1: Version present, 6 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 0|0|0|0|1| Version number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | packet num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 2: Connection ID present, 10 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 0|1|0|0|0| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | packet num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 3: Connection ID and version present, or version negotiation, 14 = octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 0|1|0|0|1| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Version number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | packet num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 4: flags and packet number, 3 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 1|0|0|0|1| packet number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 5: Version present, 7 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 1|0|0|0|1| Version number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | packet number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 6: Connection ID present, 11 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 1|1|0|0|0| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | packet number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 7: Connection ID and version present, or version negotiation, 15 = octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0 1|1|0|0|1| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Version number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | packet number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 8: flags and packet number, 5 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 0|0|0|0|1| packet number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | +-+-+-+-+-+-+-+-+ Header 9: Version present, 9 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 0|0|0|0|1| Version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | packet number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | +-+-+-+-+-+-+-+-+ Header 10: Connection ID present, 13 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 0|1|0|0|0| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | packet number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | +-+-+-+-+-+-+-+-+ Header 11: Connection ID and version present, or version negotiation, 17 = octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 0|1|0|0|1| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Version number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | packet number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | +-+-+-+-+-+-+-+-+ Header 12: flags and packet number, 9 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 1|0|0|0|1| | +-+-+-+-+-+-+-+-+ packet number | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Header 13: Version present, 13 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 1|0|0|0|1| Version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | | +-+-+-+-+-+-+-+-+ packet number | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Header 14: Connection ID present, 17 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 1|1|0|0|0| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ packet number | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Header 15: Connection ID and version present, or version negotiation, 21 = octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1 1|1|0|0|1| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Version number . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (cont'd) | | +-+-+-+-+-+-+-+-+ packet number | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Header 16: Public Reset, no version or packet number, 9 octets. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|? ?|1|0|1|0| | +-+-+-+-+-+-+-+-+ Connection ID | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ --Apple-Mail=_3B957A45-B75D-469A-BE67-B83D223C18B8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYdk/MAAoJEIoSt78L6kajTLkQAJqfM30wX1SJv5EfXabcED1P rdQB5butTOQXKz0CF1VZV/rZdtueo6dtKdp3tSwn7A1+iVQW+vpn+Ez85nyhI2Hu U4SbC04RBX3FmiyrL1dltdPgN9egDwq3R0APT8Y1hjrof8ylH9d6yl9EyAvAqGOi 4HR1meVzPCYpAbN23ygkHzPUwYdx1f20IElgNG6AlV3HEmqAgYJflqhOoMn50lm1 j2HvbTq0wTqCsdV2FbYeMVjf7mipOejES6fjP5vXrvBq7Bpar26H50QbR7NB8w96 G6pjPrVGRToqDZrF8Nvby50H3zxaxEYRY/J1Ywszohy+yEron/UM/WL4UYVEBk3+ GC+pFvyuJzIspdDwOTSvGIGFXgq6A6vHy2VmyqnCfQxd6PEayKBqVS1ZjdJrlETK DN+/S8KoZ5TF7NeMbcQwXd3vCTaMD0WEYdz0m46AC3IHU4B20rdMNW7IN8POd3BF qcR+0iOtvMfdRd3ewcp/K4WOJ4Wr4pCrUrMzyTaUwtLkUOnbVf5l5BcFAyfnVHTX UNLqOipUtM36LrWIJIc/5YJTngXMkFXklSX+IdAb0lNDlX51YOTy7PSPxR3kUzmr bVgacPrmkJlDuBH0c9Qb4Bbbc2t1pZu5LXC4sznvKirEwyHd7CU6eVcOJC9wx3fs LG6WWvzUM+/6fYF0LyD6 =bnqW -----END PGP SIGNATURE----- --Apple-Mail=_3B957A45-B75D-469A-BE67-B83D223C18B8-- From nobody Wed Jan 11 10:26: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 759EE129515 for ; Wed, 11 Jan 2017 10:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph2Qimqi80aI for ; Wed, 11 Jan 2017 10:26:12 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0121.outbound.protection.outlook.com [104.47.41.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B1A126579 for ; Wed, 11 Jan 2017 10:26:11 -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=ep1hmqSzjDI7/8yAjjq/9lUkXsVLjHspoMZgUOObAao=; b=kGrty3lC30ccHZGL4/3da5FeTvmWhqP6LUU3wkP2nEr8nkuk8p+0JOI6b2UTl51p7ZISn4CFSlp8UOyHfwJ7cCcjeGff73rIu8jgs6a06/4Lp9zhJ76hwN7zQI+k8gQSNk+0hzagzKlGiYaVqDRto54iF+/xGXDWKuhKyoGqfHE= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 11 Jan 2017 18:26:10 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0845.013; Wed, 11 Jan 2017 18:26:10 +0000 From: Mike Bishop To: IETF QUIC WG Subject: Using different crypto Thread-Topic: Using different crypto Thread-Index: AdJqwmguSJ5RH5YtRcG/iV7NxHADeQ== Date: Wed, 11 Jan 2017 18:26:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:9::466] x-ms-office365-filtering-correlation-id: 2ba88003-4bf2-40e0-b5d3-08d43a4f510e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:UNsdoE0zXILwme46tBYMcxowpVxzieO4KrJihxKe8QLDoZDbUiV1R5Jmm8BmYwgNPFU+nQJEDbLPJblooZX6fAUJ+HHr8ogShSemrlJvX4dEiGG+p/Y54VhDEbGji5rhtSs3oypllJVQJlhjvEyxnsTJ3+E4J88fIE3zak+OFiaf0JquL6mBQmmQiW8nGxoMuHMgt0cZGTrjp7A4hDIS5qUikn5bVakxWA/dUoy00J20nlJW+w/EBhh1dqQVlCDS3UqJoU05Wp5ks/B1LNyzOsdO8Z0OBYLfsJJHamlNEr7osTVfgz3U0fISsI1/SclunR7UrU9xj5E6Vp9E1Mz97DJjw7vRVMOKZzoebZRpRYHFC7Wp4qie2TowTJ2WvHdRoA435JtH9FXzxCkGZZaJQ/uwhFYAIgF54CAq4W56oPAFx2+KEcTe3IgYmYd1tXbO1+1Bg4XeNo/1xnF1ek0yE0+IcamIiA23hY9TSmbELIo= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(199003)(189002)(6306002)(55016002)(74316002)(54896002)(54906002)(6506006)(99286003)(7736002)(6916009)(6436002)(92566002)(54356999)(25786008)(3280700002)(4326007)(2906002)(50986999)(101416001)(10090500001)(2900100001)(790700001)(6116002)(102836003)(122556002)(106356001)(105586002)(9686003)(5660300001)(97736004)(189998001)(33656002)(7116003)(110136003)(77096006)(7696004)(39060400001)(38730400001)(86362001)(68736007)(8936002)(3660700001)(86612001)(3480700004)(8676002)(8990500004)(81166006)(81156014)(5005710100001)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708EE7EAA4C2416D1F9F6D387660BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 18:26:10.0376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: Jana Iyengar , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 18:26:13 -0000 --_000_BN6PR03MB2708EE7EAA4C2416D1F9F6D387660BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There's a document structure decision that needs feedback from the WG. We = know that we have a very logical document break between the core transport = and how TLS behaves. The question is how sharp that division needs to be. = There are two obvious paths here: * Quic-transport depends on quic-tls. A future RFC defining QUIC with = a different crypto protocol would describe the deviations from quic-transpo= rt required to accommodate the new crypto protocol, and would contain the e= quivalent of quic-tls for the alternate security protocol. * Quic-transport defines requirements for the crypto protocol, whatever= it may be, and specifies an interface. Quic-tls describes how TLS is used= to satisfy those requirements and defines a version of QUIC using TLS. A = future RFC would define how a different crypto protocol could be used to sa= tisfy the same requirements and establishes a different version number for = that combination. At the moment, this is somewhat academic, since TLS is the only crypto prot= ocol we're chartered to actually define. However, it affects how much quic= -transport can "know" about TLS. For example, the current draft has a sect= ion on requirements for the crypto protocol. Various pending PRs propose r= eplacing this with specific references to TLS. However, there is anecdotal= interest in having other crypto protocols in other scenario. How abstract do we want to be here? --_000_BN6PR03MB2708EE7EAA4C2416D1F9F6D387660BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There’s a document structure decision that nee= ds feedback from the WG.  We know that we have a very logical document= break between the core transport and how TLS behaves.  The question i= s how sharp that division needs to be.  There are two obvious paths here:

 

  • Quic-transport depends on quic-tls.  A future RFC defining QUIC = with a different crypto protocol would describe the deviations from quic-tr= ansport required to accommodate the new crypto protocol, and would contain the equivalent of quic-tls for the alternate s= ecurity protocol.
  • Quic-transport defines requirements = for the crypto protocol, whatever it may be, and specifies an interface.&nb= sp; Quic-tls describes how TLS is used to satisfy those requirements and de= fines a version of QUIC using TLS.  A future RFC would define how a differe= nt crypto protocol could be used to satisfy the same requirements and estab= lishes a different version number for that combination.

    •  

    At the moment, this is somewhat academic, since TLS = is the only crypto protocol we’re chartered to actually define. = However, it affects how much quic-transport can “know” about T= LS.  For example, the current draft has a section on requirements for the crypto protocol.  Various pending PRs propose replacing this = with specific references to TLS.  However, there is anecdotal interest= in having other crypto protocols in other scenario.

     

    How abstract do we want to be here?

--_000_BN6PR03MB2708EE7EAA4C2416D1F9F6D387660BN6PR03MB2708namp_-- From nobody Wed Jan 11 10:46: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 3E6C5129D4B for ; Wed, 11 Jan 2017 10:46:50 -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 qeqGC1JfPMEc for ; Wed, 11 Jan 2017 10:46:48 -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 B242E1296BE for ; Wed, 11 Jan 2017 10:46:48 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id x49so137812501qtc.2 for ; Wed, 11 Jan 2017 10:46:48 -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=ClApHSbv/XxCOS4EV6r6N4+F6Bk5Y77KBLr+u8J6SQY=; b=DLI6a0ABZ/vGrCwDNp5kW203J/Slc6oWaVupMCzTuxKX4kQqMJ2bgW7biAeQuLK0F/ j75KtjJIyi9YpoD6yNw0QLY0N7hYFJss4s+2OpV/FtNbQew8x+QipcP1U/U4NZzJK5b0 ng8L7faUonBA4aMEXzQ1JGZc+51GYxhqA8fbmQJU4IyZ+9OAszWRsfaMN8RDwHo94Atc XjCT2t/ApWvfZQkTfS+DC4nIkQSkQkkW9OOTIe9vbNphIAvsooCJTwj+OJMdt7t3zk6D K6beKn6yybvkeAZi9C7GSdQRyLi0COYjuky2fm6Rmi7Z9h7rtOe5N9LgOOhIl3WlwQab KY1A== 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=ClApHSbv/XxCOS4EV6r6N4+F6Bk5Y77KBLr+u8J6SQY=; b=m59Q5ZRKmqwEdVfBe7DGRBS272E/mg0lpwU3FwpxG8sgPy7uerI50FTaeJQDHiDU3l Fr9L7oKfOUAQ3V3/DCM6cdcTwFJUqjC7gga6mnMaG46u0b+4w5veZItobey+gy8IQPY1 0pZHLe1hVJIPnT5IgFiWnMFKKBWAKk0HPXAgNhUM/DvyvdR8iDca5+9AwTVN3bNFhdVv C0ur3RC4CZ5uDWrE06Dyuv3MAbYtPmmFquCKuSos1iuGPj58YtHwqsN6UkWQUwMkyxD3 t3i9Rjz148jFSU1qFh2quWjAWrX/7vrPWYyO5Oar+fYcKxf65V7w5eX/5mTL/P2bGtoR +b1g== X-Gm-Message-State: AIkVDXIMi7minkyVln+7BTY+v/BQ3EU1Vw0rycSzh+myq0KWnDsZaHFHSQ8PDhrdt7H7D0JK8U3otrhmRZVRvA== X-Received: by 10.200.47.84 with SMTP id k20mr8825263qta.119.1484160407651; Wed, 11 Jan 2017 10:46:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.182.66 with HTTP; Wed, 11 Jan 2017 10:46:17 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Wed, 11 Jan 2017 10:46:17 -0800 Message-ID: Subject: Re: Using different crypto To: Mike Bishop Content-Type: multipart/alternative; boundary=001a11358752e365350545d6051b Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 18:46:50 -0000 --001a11358752e365350545d6051b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, On Wed, Jan 11, 2017 at 10:26 AM, Mike Bishop wrote: > There=E2=80=99s a document structure decision that needs feedback from th= e WG. We > know that we have a very logical document break between the core transpor= t > and how TLS behaves. The question is how sharp that division needs to be= . > There are two obvious paths here: > > > > - Quic-transport depends on quic-tls. A future RFC defining QUIC with > a different crypto protocol would describe the deviations from > quic-transport required to accommodate the new crypto protocol, and wo= uld > contain the equivalent of quic-tls for the alternate security protocol= . > - Quic-transport defines requirements for the crypto protocol, > whatever it may be, and specifies an interface. Quic-tls describes ho= w TLS > is used to satisfy those requirements and defines a version of QUIC us= ing > TLS. A future RFC would define how a different crypto protocol could = be > used to satisfy the same requirements and establishes a different vers= ion > number for that combination. > > So, I personally prefer the second style. That's partly because we may someday have other crypto protocols, but mostly because it means that when TLS evolves an updated RFC describing how to use the new facilities doesn't need to update the transport document. > > At the moment, this is somewhat academic, since TLS is the only crypto > protocol we=E2=80=99re chartered to actually define. However, it affects= how much > quic-transport can =E2=80=9Cknow=E2=80=9D about TLS. For example, the cu= rrent draft has a > section on requirements for the crypto protocol. Various pending PRs > propose replacing this with specific references to TLS. However, there i= s > anecdotal interest in having other crypto protocols in other scenario. > > > > How abstract do we want to be here? > We recently saw PERC depend on a specific set of functions in TLS 1.2, then discover that 1.3 shifted the ground enough that PERC's methods need to be rethought or PERC kept to an older version of TLS. That's a recent enough proof point, at least in my mind, that we should focus on having the transport treat the interface to the crypto protocol at a more abstract level. Just my personal opinion, Ted --001a11358752e365350545d6051b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

On Wed, Jan 11, 2017 at 10:26 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

There=E2=80=99s a document structure decision that n= eeds feedback from the WG.=C2=A0 We know that we have a very logical docume= nt break between the core transport and how TLS behaves.=C2=A0 The question= is how sharp that division needs to be.=C2=A0 There are two obvious paths here:

=C2=A0

  • Quic-transport depends on quic-tls.=C2=A0 A future RFC defining QUIC wi= th a different crypto protocol would describe the deviations from quic-tran= sport required to accommodate the new crypto protocol, and would contain the equivalent of quic-tls for the alternate s= ecurity protocol.
  • Quic-transport defines requirements= for the crypto protocol, whatever it may be, and specifies an interface.= =C2=A0 Quic-tls describes how TLS is used to satisfy those requirements and= defines a version of QUIC using TLS.=C2=A0 A future RFC would define how a differe= nt crypto protocol could be used to satisfy the same requirements and estab= lishes a different version number for that combination.
    • <= /ul>

So, I perso= nally prefer the second style.=C2=A0 That's partly because we may somed= ay have other crypto protocols, but mostly because it means that when TLS e= volves an updated RFC describing how to use the new facilities doesn't = need to update the transport document.=C2=A0

=C2=A0

At the moment, this is somewhat academic, since TLS = is the only crypto protocol we=E2=80=99re chartered to actually define.=C2= =A0 However, it affects how much quic-transport can =E2=80=9Cknow=E2=80=9D = about TLS.=C2=A0 For example, the current draft has a section on requiremen= ts for the crypto protocol.=C2=A0 Various pending PRs propose replacing this = with specific references to TLS.=C2=A0 However, there is anecdotal interest= in having other crypto protocols in other scenario.

=C2=A0

How abstract do we want to be here?


We recently saw PER= C depend on a specific set of functions in TLS 1.2, then discover that 1.3 = shifted the ground enough that PERC's methods need to be rethought or P= ERC kept to an older version of TLS.=C2=A0 That's a recent enough proof= point, at least in my mind, that we should focus on having the transport t= reat the interface to the crypto protocol at a more abstract level.

=
Just my personal opinion,

Ted
--001a11358752e365350545d6051b-- From nobody Wed Jan 11 10:48:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FDC129D4F for ; Wed, 11 Jan 2017 10:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 WCCPGwBkgZBD for ; Wed, 11 Jan 2017 10:48:01 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B861297C9 for ; Wed, 11 Jan 2017 10:48:01 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id l75so62045613ywb.0 for ; Wed, 11 Jan 2017 10:48:01 -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=b7WXX5UbNPnKWn70aflCbyrq5mNQ+bUqlT91JLPIHmM=; b=Hp6XD+NEXTnkZ3IWiwt8WEwxxro3z71MyxgyaRI1HlvvvrCqz8bdXCBwG3uRTWouZq U1k+g8e5u7CUI+AkYx7GTO7PeRTHBCXZXi+Ix2oXXLVQEUpEQEqau4p8nDe3LEybEJea fOQIR/ENLDO/BilSXg2OcmnSAA9r2WTWU5GlqxWX0GJ435UqtoSfupm8GZG10YAaPw17 nkWkcxIw3CS/xpXTcESTCRcDSrorg9uP8RBz8k95yxLDCStI5GFKouscg8jE/kFPHc9n JHu82XwsuiezD//FMRWz6cD0QR+v7OF/DJtHudvYxRHzeynp5193cFor9A15BWMn47Bj CtiA== 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=b7WXX5UbNPnKWn70aflCbyrq5mNQ+bUqlT91JLPIHmM=; b=hvdC6kYJbys2GL4u6Wds3BLA9WyKLm76maHAs6xYDsHnWdmS91sQofkEd1fLTus0lM UMbdR/Gc51Af96eJjR/XuCqydDQO3j4x5MeyJJvSuQQlTlCEKMytyvu5+9RZUg6NrI4b JqsRbmVpEeoNRzHcx8WIUqJ+p7Z963GWEsPkymIAnmMthYIm+/3NN3YVO6awzmq1YAS+ ygfN23NJ1usJRKEsJDMIJ8XxeABxBBhztsy78SIZYA1IBZrJ1yUf0Up7x4dBxq9lTeN8 VoaDCZNU3DibBojIcIOI38bS4JAvBtesm5fPz2nr7inSwLHhMTHSxm7jRzua87+ATc82 cv8w== X-Gm-Message-State: AIkVDXJ42Rv9fXFrUIInMAxl02/GrE/vpZNtuMpXr960DuuNbXXxq7+Y7gNFFUU1OPkKatwat1FDkQwgIi7mjE7A X-Received: by 10.129.90.134 with SMTP id o128mr9066243ywb.63.1484160480928; Wed, 11 Jan 2017 10:48:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Wed, 11 Jan 2017 10:47:40 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Wed, 11 Jan 2017 13:47:40 -0500 Message-ID: Subject: Re: Using different crypto To: Mike Bishop Content-Type: multipart/alternative; boundary=001a114922e2425e5a0545d60a4c Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 18:48:03 -0000 --001a114922e2425e5a0545d60a4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would like Quic-transport to define requirements for a crypto protocol, otherwise it will become hard or impossible to use another type of handshake. WebRTC seems like an obvious example, but I'm sure there are others. On Wed, Jan 11, 2017 at 1:26 PM, Mike Bishop wrote: > There=E2=80=99s a document structure decision that needs feedback from th= e WG. We > know that we have a very logical document break between the core transpor= t > and how TLS behaves. The question is how sharp that division needs to be= . > There are two obvious paths here: > > > > - Quic-transport depends on quic-tls. A future RFC defining QUIC with > a different crypto protocol would describe the deviations from > quic-transport required to accommodate the new crypto protocol, and wo= uld > contain the equivalent of quic-tls for the alternate security protocol= . > - Quic-transport defines requirements for the crypto protocol, > whatever it may be, and specifies an interface. Quic-tls describes ho= w TLS > is used to satisfy those requirements and defines a version of QUIC us= ing > TLS. A future RFC would define how a different crypto protocol could = be > used to satisfy the same requirements and establishes a different vers= ion > number for that combination. > > > > At the moment, this is somewhat academic, since TLS is the only crypto > protocol we=E2=80=99re chartered to actually define. However, it affects= how much > quic-transport can =E2=80=9Cknow=E2=80=9D about TLS. For example, the cu= rrent draft has a > section on requirements for the crypto protocol. Various pending PRs > propose replacing this with specific references to TLS. However, there i= s > anecdotal interest in having other crypto protocols in other scenario. > > > > How abstract do we want to be here? > --001a114922e2425e5a0545d60a4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like Quic-transport to define requirements for a c= rypto protocol, otherwise it will become hard or impossible to use another = type of handshake.=C2=A0 WebRTC seems like an obvious example, but I'm = sure there are others.



On Wed, Jan 11, 2017 at 1:26 PM, M= ike Bishop <Michael.Bishop@microsoft.com> wrote:<= br>

There=E2=80=99s a document structure decision that n= eeds feedback from the WG.=C2=A0 We know that we have a very logical docume= nt break between the core transport and how TLS behaves.=C2=A0 The question= is how sharp that division needs to be.=C2=A0 There are two obvious paths here:

=C2=A0

  • Quic-transport depends on quic-tls.=C2=A0 A future RFC defining QUIC wi= th a different crypto protocol would describe the deviations from quic-tran= sport required to accommodate the new crypto protocol, and would contain the equivalent of quic-tls for the alternate s= ecurity protocol.
  • Quic-transport defines requirements= for the crypto protocol, whatever it may be, and specifies an interface.= =C2=A0 Quic-tls describes how TLS is used to satisfy those requirements and= defines a version of QUIC using TLS.=C2=A0 A future RFC would define how a differe= nt crypto protocol could be used to satisfy the same requirements and estab= lishes a different version number for that combination.
    • <= /ul>

    =C2=A0

    At the moment, this is somewhat academic, since TLS = is the only crypto protocol we=E2=80=99re chartered to actually define.=C2= =A0 However, it affects how much quic-transport can =E2=80=9Cknow=E2=80=9D = about TLS.=C2=A0 For example, the current draft has a section on requiremen= ts for the crypto protocol.=C2=A0 Various pending PRs propose replacing this = with specific references to TLS.=C2=A0 However, there is anecdotal interest= in having other crypto protocols in other scenario.

    =C2=A0

    How abstract do we want to be here?


--001a114922e2425e5a0545d60a4c-- From nobody Wed Jan 11 11:06: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 EA882129F43 for ; Wed, 11 Jan 2017 11:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 Yot6GF323Rli for ; Wed, 11 Jan 2017 11:06:43 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284CC129D76 for ; Wed, 11 Jan 2017 11:06:43 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id c85so166429704wmi.1 for ; Wed, 11 Jan 2017 11:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fWjHuwFMd28FPze5i3sQI0Dcivt3sGAC9SpjIbK7wk8=; b=V/7d+ne54yI3Bs/yixvE2CsalHp5m5ppDBtsWghlizgfWhSKpTtm7uWDFw80r8Gc8q uV56Mtyk6wZsYX4ClYPZZOZDLDcfOQ+6AiqqrGKnopp6GrwihZinToqYNAhCTi+E6uio vvyj9f5Ci4NQ3e4I4/rvGjyF8sbVEOv2cEY0cUGu4jmIRqzzVshkvl99+hjG1LfDUZqT k+x86/bHxJYNF52D6ev+PA8gOFxksPbYr1/Izq8Ii63RiNV9O499dsm+L4yTOoHBm98R 8WejE9+Sr/6ISwHadoxBIwzvu3x7iUO1zMKSOBIm5Mw4/guXbLWcVWn23Cf6tuBRT6xI 8RvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fWjHuwFMd28FPze5i3sQI0Dcivt3sGAC9SpjIbK7wk8=; b=SPtxQaclCxNl2yiHft6IMOm2vS9uLcF4VPgFl67Nf6lxd6ArrNGQs6l/XaB6rsF2wb 464ulGvgswLvBgumGZKBjwDJoAZk4Z9FLYj0NzJQLZraRHz8JyYnx1wUCu5Fz8Lm+6Jq XzFIBgwBcKTCyGdWXI0NWngutUhMzcPiXQDMHOZyGpTtmdpbTwrLyU04Mop3QQtCpUbo GuPMkwrqTXP2IridfVCmnv1sKYETsJ0Q2bAMPh2d7LTQI0GmCo2rbq7PaimutMuDGWyt vmEOV1SA8oZi3ae07SSPIMz3M8qeWLtFJHjhMEkw2NDmxrPQJAwnAaE6iA1jd+5w5Xfd qMfQ== X-Gm-Message-State: AIkVDXIZGI0uylB508hL59zrVt7gsgQ2hSY5uC5+SWTHq7qkcJMMmYQZNxGPcViQk3puFFI7dTmyYCobus4wZg== X-Received: by 10.223.174.1 with SMTP id x1mr4762105wrc.126.1484161601600; Wed, 11 Jan 2017 11:06:41 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Wed, 11 Jan 2017 11:06:40 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 11 Jan 2017 14:06:40 -0500 X-Google-Sender-Auth: S-Fy1f8xNsqLJvncSpPTrw5mF-k Message-ID: Subject: Re: Using different crypto To: Ted Hardie Content-Type: multipart/alternative; boundary=94eb2c1cd8b80d87060545d64d1d Archived-At: Cc: Mike Bishop , IETF QUIC WG , Martin Thomson , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Jan 2017 19:06:45 -0000 --94eb2c1cd8b80d87060545d64d1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Ted. The key agreements in TLS are based on a design started in the 1990s and are a little odd to say the least. The client auth in particular is... Ephemeral key agreement is done in a really bad way. So I would expect to find us doing a redesign of TLS at some point. But that isn't something I would want to do until after QUIC. One of the chief requirements for QUIC deployment is going to be having a negotiation mechanism. And hopefully that makes use of DNSSEC. And hopefully that mechanism provides for encrypting the domain name during the connection. It might well be plausible to make use of client auth keys as well. Adapting TLS to just one of those requirements is possible but probably not worth the effort. Trying to meet all three would cause the Jenga tower to collapse, TLS is already too complex. So please don't weld QUIC to TLS. On Wed, Jan 11, 2017 at 1:46 PM, Ted Hardie wrote: > Howdy, > > On Wed, Jan 11, 2017 at 10:26 AM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > >> There=E2=80=99s a document structure decision that needs feedback from t= he WG. >> We know that we have a very logical document break between the core >> transport and how TLS behaves. The question is how sharp that division >> needs to be. There are two obvious paths here: >> >> >> >> - Quic-transport depends on quic-tls. A future RFC defining QUIC >> with a different crypto protocol would describe the deviations from >> quic-transport required to accommodate the new crypto protocol, and w= ould >> contain the equivalent of quic-tls for the alternate security protoco= l. >> - Quic-transport defines requirements for the crypto protocol, >> whatever it may be, and specifies an interface. Quic-tls describes h= ow TLS >> is used to satisfy those requirements and defines a version of QUIC u= sing >> TLS. A future RFC would define how a different crypto protocol could= be >> used to satisfy the same requirements and establishes a different ver= sion >> number for that combination. >> >> So, I personally prefer the second style. That's partly because we may > someday have other crypto protocols, but mostly because it means that whe= n > TLS evolves an updated RFC describing how to use the new facilities doesn= 't > need to update the transport document. > > >> >> At the moment, this is somewhat academic, since TLS is the only crypto >> protocol we=E2=80=99re chartered to actually define. However, it affect= s how much >> quic-transport can =E2=80=9Cknow=E2=80=9D about TLS. For example, the c= urrent draft has a >> section on requirements for the crypto protocol. Various pending PRs >> propose replacing this with specific references to TLS. However, there = is >> anecdotal interest in having other crypto protocols in other scenario. >> >> >> >> How abstract do we want to be here? >> > > We recently saw PERC depend on a specific set of functions in TLS 1.2, > then discover that 1.3 shifted the ground enough that PERC's methods need > to be rethought or PERC kept to an older version of TLS. That's a recent > enough proof point, at least in my mind, that we should focus on having t= he > transport treat the interface to the crypto protocol at a more abstract > level. > > Just my personal opinion, > > Ted > --94eb2c1cd8b80d87060545d64d1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I a= gree with Ted.
=
The key ag= reements in TLS are based on a design started in the 1990s and are a little= odd to say the least. The client auth in particular is... Ephemeral key ag= reement is done in a really bad way.

So I would expect to find us doing a redesign of TLS at some po= int. But that isn't something I would want to do until after QUIC.

One of the chief requirements= for QUIC deployment is going to be having a negotiation mechanism. And hop= efully that makes use of DNSSEC. And hopefully that mechanism provides for = encrypting the domain name during the connection. It might well be plausibl= e to make use of client auth keys as well.

Adapting TLS to just one of those requirements is possibl= e but probably not worth the effort. Trying to meet all three would cause t= he Jenga tower to collapse, TLS is already too complex.

So please don't weld QUIC to TLS.
<= div class=3D"gmail_default" style=3D"font-size:small">






On Wed, Jan 11, 2017 at 1:46 PM, Ted Hardie <ted.ietf@gmail.com&g= t; wrote:
Howdy,<= br>

On Wed, Jan 11, 2017 at 10:26 AM, Mike Bishop <= ;Michael.= Bishop@microsoft.com> wrote:

There=E2=80=99s a document structure decision that n= eeds feedback from the WG.=C2=A0 We know that we have a very logical docume= nt break between the core transport and how TLS behaves.=C2=A0 The question= is how sharp that division needs to be.=C2=A0 There are two obvious paths here:

=C2=A0

  • Quic-transport depends on quic-tls.=C2=A0 A futur= e RFC defining QUIC with a different crypto protocol would describe the dev= iations from quic-transport required to accommodate the new crypto protocol, and would contain the equivalent of quic-tls for the alternate s= ecurity protocol.
  • Quic-transpor= t defines requirements for the crypto protocol, whatever it may be, and spe= cifies an interface.=C2=A0 Quic-tls describes how TLS is used to satisfy th= ose requirements and defines a version of QUIC using TLS.=C2=A0 A future RFC would define how a differe= nt crypto protocol could be used to satisfy the same requirements and estab= lishes a different version number for that combination.
    • <= /ul>

So, = I personally prefer the second style.=C2=A0 That's partly because we ma= y someday have other crypto protocols, but mostly because it means that whe= n TLS evolves an updated RFC describing how to use the new facilities doesn= 't need to update the transport document.=C2=A0

=C2=A0

At the moment, this is somewhat academic, since TLS = is the only crypto protocol we=E2=80=99re chartered to actually define.=C2= =A0 However, it affects how much quic-transport can =E2=80=9Cknow=E2=80=9D = about TLS.=C2=A0 For example, the current draft has a section on requiremen= ts for the crypto protocol.=C2=A0 Various pending PRs propose replacing this = with specific references to TLS.=C2=A0 However, there is anecdotal interest= in having other crypto protocols in other scenario.

=C2=A0

How abstract do we want to be here?


We recently = saw PERC depend on a specific set of functions in TLS 1.2, then discover th= at 1.3 shifted the ground enough that PERC's methods need to be rethoug= ht or PERC kept to an older version of TLS.=C2=A0 That's a recent enoug= h proof point, at least in my mind, that we should focus on having the tran= sport treat the interface to the crypto protocol at a more abstract level.<= br>
Just my personal opinion,

Ted

--94eb2c1cd8b80d87060545d64d1d-- From nobody Wed Jan 11 11:07: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 B860D129F4B for ; Wed, 11 Jan 2017 11:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0ag76qOQEE0 for ; Wed, 11 Jan 2017 11:07:32 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id C307E129F45 for ; Wed, 11 Jan 2017 11:07:32 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3C1A5433430; Wed, 11 Jan 2017 19:07:32 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 25F1A43342F; Wed, 11 Jan 2017 19:07:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484161652; bh=FHFIyFgF3AGej5dkkRFcUsGHkKWnqqed/fDNjRc+ev0=; l=634; h=From:To:CC:Date:References:In-Reply-To:From; b=pkweSt8s2DCswyKLyksYT/nsg6pVTtmcoKsoOwK74tN4pSeG7AJg87pqCTT7/2O6M 2eKini59J1r1k/jOMLU7oqUtraJJFgyVzCD73QK97NMQ0wEqN+Z+uGHLvwMKDoTgT+ 6Vx4tD80DhSaRBHF1JA6+RHguRcJ+yFsw8DpOzh8= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 1DA681FC9D; Wed, 11 Jan 2017 19:07:32 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 11 Jan 2017 14:07:31 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 11 Jan 2017 14:07:31 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 11 Jan 2017 14:07:31 -0500 From: "Salz, Rich" To: Ted Hardie , Mike Bishop Subject: RE: Using different crypto Thread-Topic: Using different crypto Thread-Index: AdJqwmguSJ5RH5YtRcG/iV7NxHADeQBon6CAAAnFW6A= Date: Wed, 11 Jan 2017 19:07:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:07:36 -0000 PiBTbywgSSBwZXJzb25hbGx5IHByZWZlciB0aGUgc2Vjb25kIHN0eWxlLsKgIFRoYXQncyBwYXJ0 bHkgYmVjYXVzZSB3ZSBtYXkgc29tZWRheSBoYXZlIG90aGVyIGNyeXB0byBwcm90b2NvbHMsIGJ1 dCBtb3N0bHkgYmVjYXVzZSBpdCBtZWFucyB0aGF0IHdoZW4gVExTIGV2b2x2ZXMgYW4gdXBkYXRl ZCBSRkMgZGVzY3JpYmluZyBob3cgdG8gdXNlIHRoZSBuZXcgZmFjaWxpdGllcyBkb2Vzbid0IG5l ZWQgdG8gdXBkYXRlIHRoZSB0cmFuc3BvcnQgZG9jdW1lbnQuwqAgDQoNCkFub3RoZXIgcmVhc29u IHdoeSBJIHByZWZlciAjMiBpcyB0aGF0IGl0IG1pZ2h0IGVuYWJsZWQgInN0cmlwcGVkIGRvd24i IFRMUyBzdGFja3MgdGhhdCBhcmUgb3B0aW1pemVkIG9ubHkgdG8gc3VwcG9ydCBRVUlDLiAgVGhh dCBzZWVtcyBsaWtlIGEgZ29vZCB0aGluZyB0byBiZSBhYmxlIHRvIGRvLCBlLmcuLCBmb3IgSW9U LiANCg== From nobody Wed Jan 11 11:23: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 1B45B129F4B for ; Wed, 11 Jan 2017 11:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8Y77H5f5G45 for ; Wed, 11 Jan 2017 11:23:37 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id AD19C1294D8 for ; Wed, 11 Jan 2017 11:23:37 -0800 (PST) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id E310C3A0B2 for ; Wed, 11 Jan 2017 14:23:36 -0500 (EST) Received: by mail-qk0-f182.google.com with SMTP id 11so120969601qkl.3 for ; Wed, 11 Jan 2017 11:23:36 -0800 (PST) X-Gm-Message-State: AIkVDXLLU6p5xGta3JAMUnHWsv6xkKtXk5qsQULkYbk/VNZenAba6r0ObE9DAoDSMc5xSZy3gwOYmNoqv2/GZw== X-Received: by 10.55.101.215 with SMTP id z206mr9230429qkb.35.1484162616580; Wed, 11 Jan 2017 11:23:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.157.12 with HTTP; Wed, 11 Jan 2017 11:23:36 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Wed, 11 Jan 2017 14:23:36 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Using different crypto To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114812f28ce54d0545d6898c Archived-At: Cc: Mike Bishop , Ted Hardie , IETF QUIC WG , Martin Thomson , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Jan 2017 19:23:39 -0000 --001a114812f28ce54d0545d6898c Content-Type: text/plain; charset=UTF-8 Folks interested in this who aren't reading the github comment traffic (highly recommended fwiw) will find https://github.com/quicwg/base-drafts/pull/122 useful reading. To me this largely boils down to whether we want to add a crypto negotiation mechanism or just tie it to the transport versioning. I think in a practical sense what we have (transport versioning) is sufficient and makes it much easier to feel confident and reason about version 1. (That would be support for option 1.) -Patrick On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich wrote: > > So, I personally prefer the second style. That's partly because we may > someday have other crypto protocols, but mostly because it means that when > TLS evolves an updated RFC describing how to use the new facilities doesn't > need to update the transport document. > > Another reason why I prefer #2 is that it might enabled "stripped down" > TLS stacks that are optimized only to support QUIC. That seems like a good > thing to be able to do, e.g., for IoT. > --001a114812f28ce54d0545d6898c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks interested in this who aren't reading the g= ithub comment traffic (highly recommended fwiw) will find https://github.com/quicwg/base-dr= afts/pull/122 useful reading.

To me this = largely boils down to whether we want to add a crypto negotiation mechanism= or just tie it to the transport versioning. I think in a practical sense w= hat we have (transport versioning) is sufficient and makes it much easier t= o feel confident and reason about version 1. (That would be support for opt= ion 1.)

-Patrick




On Wed, Jan 11, 201= 7 at 2:07 PM, Salz, Rich <rsalz@akamai.com> wrote:
> So, I personally prefer the s= econd style.=C2=A0 That's partly because we may someday have other cryp= to protocols, but mostly because it means that when TLS evolves an updated = RFC describing how to use the new facilities doesn't need to update the= transport document.=C2=A0

Another reason why I prefer #2 is that it might enabled "stripp= ed down" TLS stacks that are optimized only to support QUIC.=C2=A0 Tha= t seems like a good thing to be able to do, e.g., for IoT.

--001a114812f28ce54d0545d6898c-- From nobody Wed Jan 11 11:42:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E352C129572 for ; Wed, 11 Jan 2017 11:42:42 -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 XriROHHy5XGz for ; Wed, 11 Jan 2017 11:42:40 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 CA89412953D for ; Wed, 11 Jan 2017 11:42:40 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id w204so101875739oiw.0 for ; Wed, 11 Jan 2017 11:42:40 -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=waNLWB5vF9XSv5FfcbI+nmuLpW5VW5euL43fLr+Wy68=; b=MrRuQL9Jm2dss4wMGv7fyjkunvKfn1g+NsIrdT6+YmEb7aGGCPZFj6jguQLqJiZGcI cdYVlvbuDkWU4lvK1zZtfjmPP1Yq2iDaqAXmN5YCsKyNOYOP0gExSswvapySuuwPwnlH 2CLNEQ4C5LuXihB+i0OPL4H2CK5vpVbmkneRA84W7WXGVbZ17+jnWOTIYRyVCVS/xHdX B4YqZnqFPUW+ibMZSl9OYNCrfv491fpQNB2iRu2XrjlSmXEfEco+WHvNjZjhMQAslZbS Y6snPW8EqERF24YhZDasS5+PtMn3UiBxe4hBezftgId3Br9EqogjFvex3Ld3D7ycYIz3 f8bw== 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=waNLWB5vF9XSv5FfcbI+nmuLpW5VW5euL43fLr+Wy68=; b=AlCdvyTQF+0yuDiudHBGRcMXfO/LqQ2FSrzqvvnrK6Q2GOexX+wCwQp2jSxwyBzoXx ojGJG8n66OFmPMUYuQX+s3qd6Mbm18kLvosACz2sq9+Xrvmgt0pkJn6DvDFyTwnlTRnw 4I/WYidvurX1/8KCGNsYAsSgfLkW2etcaAFphgzTD2W3hU4D45Pygm7dNArfqSjxDdXV HRXr/KvBUDOog+95pHgPT3Vm5karsAuOV4mQkAjifxHyQ1plSdLDPUVXDZMJ1tJLvmgi sSFSy7cibjxv24efK+efJ29Sm07RqNp7vbGlOvAmYOErqnTMCsM7wsnr0mbFs2EDq/ll OGkg== X-Gm-Message-State: AIkVDXIvs1GnGQdFxp7yifN3OqWYqXDi9DS0sJAho2IiCKkCh13NJFp/8mBcxU0Gby5UsKizYZmCmUQW6W+Qzw== X-Received: by 10.157.35.20 with SMTP id j20mr5018943otb.167.1484163760156; Wed, 11 Jan 2017 11:42:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.38.251 with HTTP; Wed, 11 Jan 2017 11:42:39 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 11 Jan 2017 11:42:39 -0800 Message-ID: Subject: Re: Using different crypto To: Patrick McManus Content-Type: multipart/alternative; boundary=001a11354d2ab676470545d6cd08 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:42:43 -0000 --001a11354d2ab676470545d6cd08 Content-Type: text/plain; charset=UTF-8 I'm unclear as to how people envision versioning in practice. Is each non-experimental QUIC version a new RFC? Are there likely to be lots of these, or only a handful after many years? Certainly, if TCP used versioning rather than option negotiation there might be many permutations of options that would result in a high version count, so that might point to lots of versions. Relatedly, are we likely to see versions branch out into different use cases (QUIC for IoT, or whatever), or pretty much have the latest version be the best common practice? So in option (1) that Mike lays out, when the crypto handshake changes we would have a very short RFC that defines QUIC version 5, that says, "everything is the same as QUIC version 4 except that the handshake uses the foo protocol". This will get really cumbersome if different versions support different use cases. I think it is much less painful to negotiate the handshake separately (e.g. option 2). Maybe in practice that means we reserve 4 bits (or whatever) of the version number for the crypto handshake, while the other 28 bits correspond to the transport RFC. On Wed, Jan 11, 2017 at 11:23 AM, Patrick McManus wrote: > Folks interested in this who aren't reading the github comment traffic > (highly recommended fwiw) will find https://github.com/quicwg/ > base-drafts/pull/122 useful reading. > > To me this largely boils down to whether we want to add a crypto > negotiation mechanism or just tie it to the transport versioning. I think > in a practical sense what we have (transport versioning) is sufficient and > makes it much easier to feel confident and reason about version 1. (That > would be support for option 1.) > > -Patrick > > > > > On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich wrote: > >> > So, I personally prefer the second style. That's partly because we may >> someday have other crypto protocols, but mostly because it means that when >> TLS evolves an updated RFC describing how to use the new facilities doesn't >> need to update the transport document. >> >> Another reason why I prefer #2 is that it might enabled "stripped down" >> TLS stacks that are optimized only to support QUIC. That seems like a good >> thing to be able to do, e.g., for IoT. >> > > --001a11354d2ab676470545d6cd08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm unclear as to how people envision versioning in pr= actice.

Is each non-experimental QUIC version a new RFC?= Are there likely to be lots of these, or only a handful after many years? = Certainly, if TCP used versioning rather than option negotiation there migh= t be many permutations of options that would result in a high version count= , so that might point to lots of versions.

Related= ly, are we likely to see versions branch out into different use cases (QUIC= for IoT, or whatever), or pretty much have the latest version be the best = common practice?

So in option (1) that Mike lays o= ut, when the crypto handshake changes we would have a very short RFC that d= efines QUIC version 5, that says, "everything is the same as QUIC vers= ion 4 except that the handshake uses the foo protocol". This will get = really cumbersome if different versions support different use cases.
<= div>
I think it is much less painful to negotiate the handsha= ke separately (e.g. option 2). Maybe in practice that means we reserve 4 bi= ts (or whatever) of the version number for the crypto handshake, while the = other 28 bits correspond to the transport RFC.


On W= ed, Jan 11, 2017 at 11:23 AM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
= Folks interested in this who aren't reading the github comment traffic = (highly recommended fwiw) will find https://github.com/quicwg/base-d= rafts/pull/122 useful reading.

To me this= largely boils down to whether we want to add a crypto negotiation mechanis= m or just tie it to the transport versioning. I think in a practical sense = what we have (transport versioning) is sufficient and makes it much easier = to feel confident and reason about version 1. (That would be support for op= tion 1.)

-Patrick



On Wed= , Jan 11, 2017 at 2:07 PM, Salz, Rich <rsalz@akamai.com> wrot= e:
> So, I personally prefer the= second style.=C2=A0 That's partly because we may someday have other cr= ypto protocols, but mostly because it means that when TLS evolves an update= d RFC describing how to use the new facilities doesn't need to update t= he transport document.=C2=A0

Another reason why I prefer #2 is that it might enabled "stripp= ed down" TLS stacks that are optimized only to support QUIC.=C2=A0 Tha= t seems like a good thing to be able to do, e.g., for IoT.


--001a11354d2ab676470545d6cd08-- From nobody Wed Jan 11 11:45: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 CB081129F6C for ; Wed, 11 Jan 2017 11:45:44 -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 IPKF1nH7txgA for ; Wed, 11 Jan 2017 11:45:37 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE800129F6B for ; Wed, 11 Jan 2017 11:45:36 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id c125so12268544ybf.1 for ; Wed, 11 Jan 2017 11:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/xQpIqmqzZ5xwE092F125OMjXWzqbnMa81UiqrqZLKc=; b=xl14/Yj1UTkbTjPXRImLMEkOx5s4f/sh0bgHpVFRuqSqn6UJsOIZo84YRvQH8+/Nqo 8U3c3IUcEyEbjGlv7hNIbqpU0GcOnHgHUZGb3ejJ7r25/kRnww1U7dPYByE7DhO3iTXb jmbZPXJkdsTM+eBVzSpbFko0FVhNoKOaTZ0PqemBs+W7Tc/KQ1sf1F2tRwSa519ZT3gE uR4xpdZIl+xhUy5BFS5gPXqstzpjys4kShAzzArURuwHwrdX2fZvKG7phytxPs9ObAN9 EZLcC4F4GPDx1saL2gCc+Aqe/NkTEmXslJcIT5UAEqatyDO9IH/lnIJKqUSd4Ur2yIlZ mY8g== 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=/xQpIqmqzZ5xwE092F125OMjXWzqbnMa81UiqrqZLKc=; b=E9+fQbRAPp8gSlZImnxPlEneHMiaiS8etmJzxLhcfgjaujozWVCoir7G7PtSTx26aH VblctSr/3t4Cw8hqReuO+bEi0E+7z+Rp2uq2WLF/EDeNFYLVzYqg+oPdfAWrDhLcBh+k 4SPunBDVLKTnE2xVaw8beEsh09v8s0Z5W5ZBGt9BLXejQuicLWGE2cZHup1e4kfGWNcE 6H4sb+qTNDW5btkgSOAEScCIJl9EDspvAK/23xS2h/R7kU9MN+J1r+6PCwFiDYlQquif /N0iW8zDJ4eSwTFzggXg62rWE4jioAFpQXBComqSGZ3yhN7vvfwhs5msrnpgS26ZDx9h k8sA== X-Gm-Message-State: AIkVDXLjskF8ouPBVk0UYjxcCF75w1yKSmV1uoWMaZNFdIktCRt31iwXOxVo3ksvFpr2yyhvyOd40aQyWfbgvA== X-Received: by 10.37.224.206 with SMTP id x197mr5255242ybg.80.1484163936134; Wed, 11 Jan 2017 11:45:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Wed, 11 Jan 2017 11:44:55 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 11 Jan 2017 11:44:55 -0800 Message-ID: Subject: Re: Using different crypto To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c0857ea33e43d0545d6d86b Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:45:44 -0000 --94eb2c0857ea33e43d0545d6d86b Content-Type: text/plain; charset=UTF-8 I basically agree with McManus here. It's really much easier to have the transport versioning and the crypto protocol advance in sequence, especially because it means you can reason about the document concretely. Responding to a few other points people raised (rather than flooding everyone's mailbox with n messages): Ted writes: > We recently saw PERC depend on a specific set of functions in TLS 1.2, then discover > that 1.3 shifted the ground enough that PERC's methods need to be rethought or PERC > kept to an older version of TLS. That's a recent enough proof point, at least in my mind, > that we should focus on having the transport treat the interface to the crypto protocol at > a more abstract level. I am familiar with the incident you are familiar with here and I think you're drawing the wrong conclusion from it. Specifically, PERC was depending on some undocumented assumptions about TLS and when those assumptions were violated, we got into trouble. That seems like it's actually fairly likely to happen here if we try to write down a set of requirements that are intended to capture what role TLS is playing here, just because layer boundaries are never as clear are you really want (and QUIC tends to push on that anyway) Ian writes: > I would like Quic-transport to define requirements for a crypto protocol, otherwise it will become > hard or impossible to use another type of handshake. WebRTC seems like an obvious example, > but I'm sure there are others. I'm pretty familiar with the case of WebRTC, and I'm having trouble seeing why it wouldn't continue to use a TLS-style handshake here. The requirements don't really change if you replace SRTP with QUIC. Rich writes: > Another reason why I prefer #2 is that it might enabled "stripped down" TLS stacks that are optimized > only to support QUIC. That seems like a good thing to be able to do, e.g., for IoT. I'm sorry, I'm not following this. Certainly that would be a good thing, but I'm not seeing how an abstraction layer helps here. What you need there is a profile of TLS. With all that said, I can see that this is a discussion we are going to have to have at the Interim -Ekr On Wed, Jan 11, 2017 at 11:23 AM, Patrick McManus wrote: > Folks interested in this who aren't reading the github comment traffic > (highly recommended fwiw) will find https://github.com/quicwg/ > base-drafts/pull/122 useful reading. > > To me this largely boils down to whether we want to add a crypto > negotiation mechanism or just tie it to the transport versioning. I think > in a practical sense what we have (transport versioning) is sufficient and > makes it much easier to feel confident and reason about version 1. (That > would be support for option 1.) > > -Patrick > > > > > On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich wrote: > >> > So, I personally prefer the second style. That's partly because we may >> someday have other crypto protocols, but mostly because it means that when >> TLS evolves an updated RFC describing how to use the new facilities doesn't >> need to update the transport document. >> >> Another reason why I prefer #2 is that it might enabled "stripped down" >> TLS stacks that are optimized only to support QUIC. That seems like a good >> thing to be able to do, e.g., for IoT. >> > > --94eb2c0857ea33e43d0545d6d86b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I basically agree with McManus here. It's really much = easier to have the transport versioning
and the crypto protocol advance= in sequence, especially because it means you can reason
about th= e document concretely.


Responding t= o a few other points people raised (rather than flooding everyone's mai= lbox
with n messages):

Ted writes:
=
> We recently saw PERC depend on a= specific set of functions in TLS 1.2, then discover
> that 1.3 shifted the ground enough that PE= RC's methods need to be rethought or PERC
> kept to an older version of TLS.=C2=A0 That'= s a recent enough proof point, at least in my mind,
> that we should focus on having the transpor= t treat the interface to the crypto protocol at
> a more abstract level.

I am familiar with the incident you are familiar with here and I thin= k you're drawing the
= wrong conclusion from it. Specifically, PERC was depending on some undocume= nted
assumptions about TL= S and when those assumptions were violated, we got into trouble.
That seems like it's actually f= airly likely to happen here if we try to write down a set of
requirements that are intended to captu= re what role TLS is playing here, just because
layer boundaries are never as clear are you really wa= nt (and QUIC tends to push on that
anyway)


Ian writes:
> I would like Quic-transport to define requirements for = a crypto protocol, otherwise it will become
> =C2=A0hard or impossible to use another type of han= dshake.=C2=A0 WebRTC seems like an obvious example,
> but I'm sure there are others.
<= div>
I'm pretty familiar with the case of WebRTC, and I'= ;m having trouble seeing why it wouldn't continue
to use a TLS-style handshake here. The require= ments don't really change if you replace SRTP
with QUIC.


Rich writes:
>=C2=A0Another reason why I prefer #2 is that it might enabled "stri= pped down" TLS stacks that are optimized
> only to support QUIC.=C2=A0 That seems like a go= od thing to be able to do, e.g., for IoT.

I&#= 39;m sorry, I'm not following this. Certainly that would be a good thin= g, but I'm not seeing how an
abstraction layer helps here. What you need there is a profile of T= LS.

With all that said, I can see that this i= s a discussion we are going to have to have at the Interim
-Ekr



=



On Wed, Jan 11, 2017 at 11:23 AM, Patrick McManus = <pmcmanus@mozilla.com> wrote:
Folks interested in this who aren't readin= g the github comment traffic (highly recommended fwiw) will find https://= github.com/quicwg/base-drafts/pull/122 useful reading.
<= div>
To me this largely boils down to whether we want to add = a crypto negotiation mechanism or just tie it to the transport versioning. = I think in a practical sense what we have (transport versioning) is suffici= ent and makes it much easier to feel confident and reason about version 1. = (That would be support for option 1.)

-Patrick



=

On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich <rsalz@a= kamai.com> wrote:
&g= t; So, I personally prefer the second style.=C2=A0 That's partly becaus= e we may someday have other crypto protocols, but mostly because it means t= hat when TLS evolves an updated RFC describing how to use the new facilitie= s doesn't need to update the transport document.=C2=A0

Another reason why I prefer #2 is that it might enabled "stripp= ed down" TLS stacks that are optimized only to support QUIC.=C2=A0 Tha= t seems like a good thing to be able to do, e.g., for IoT.


--94eb2c0857ea33e43d0545d6d86b-- From nobody Wed Jan 11 12:04: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 B15A9129580 for ; Wed, 11 Jan 2017 12:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaennasEO2Iq for ; Wed, 11 Jan 2017 12:04:54 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id A770212956F for ; Wed, 11 Jan 2017 12:04:54 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 40BB743342D; Wed, 11 Jan 2017 20:04:54 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2A578433429; Wed, 11 Jan 2017 20:04:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484165094; bh=LAJHI20tstnGGe/QKTbF+/Gc+aka+vTfrndR/VQm1cM=; l=900; h=From:To:CC:Date:References:In-Reply-To:From; b=zbazr9/KHbcOR85Zz1XhsArYGwKAGV0ExnBjpWB9Bb9vfdgeJ1lvIa6zQT2DR+TlM 9wOdf0JSpNajmzqJ8FxnJYecznycUxRfr9KpGzthXfaZcR7EsPivzle33kWCLyFMg+ G6GaoFzhy8Pq7kn1QwSUSouz7WjbR2s/x4s4MuZ8= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2665C1FC88; Wed, 11 Jan 2017 20:04:54 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 11 Jan 2017 15:04:53 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 11 Jan 2017 15:04:53 -0500 From: "Salz, Rich" To: Eric Rescorla , Patrick McManus Subject: RE: Using different crypto Thread-Topic: Using different crypto Thread-Index: AdJqwmguSJ5RH5YtRcG/iV7NxHADeQBon6CAAAnFW6D//7xCAIAABfSAgABOtQA= Date: Wed, 11 Jan 2017 20:04:53 +0000 Message-ID: <6518fb235c87465a82f8382a595ed976@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Mike Bishop , Ted Hardie , IETF QUIC WG , Martin Thomson , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Jan 2017 20:04:56 -0000 PiBJIGJhc2ljYWxseSBhZ3JlZSB3aXRoIE1jTWFudXMgaGVyZS4NCg0KTW96aWxsYSBncm91cC10 aGluayA6KQ0KDQo+ID7CoEFub3RoZXIgcmVhc29uIHdoeSBJIHByZWZlciAjMiBpcyB0aGF0IGl0 IG1pZ2h0IGVuYWJsZWQgInN0cmlwcGVkIGRvd24iIFRMUyBzdGFja3MgdGhhdCBhcmUgb3B0aW1p emVkDQo+ID4gb25seSB0byBzdXBwb3J0IFFVSUMuwqAgVGhhdCBzZWVtcyBsaWtlIGEgZ29vZCB0 aGluZyB0byBiZSBhYmxlIHRvIGRvLCBlLmcuLCBmb3IgSW9ULg0KDQo+IEknbSBzb3JyeSwgSSdt IG5vdCBmb2xsb3dpbmcgdGhpcy4gQ2VydGFpbmx5IHRoYXQgd291bGQgYmUgYSBnb29kIHRoaW5n LCBidXQgSSdtIG5vdCBzZWVpbmcgaG93IGFuDQo+IGFic3RyYWN0aW9uIGxheWVyIGhlbHBzIGhl cmUuIFdoYXQgeW91IG5lZWQgdGhlcmUgaXMgYSBwcm9maWxlIG9mIFRMUy4NCg0KQmVjYXVzZSB0 aGUgYWJzdHJhY3Rpb24gaXMgcmVhbGx5IGEgcmVxdWlyZW1lbnRzIGxheWVyLCBhcyBNaWtlIHNh aWQuICBUaGVyZWZvcmUgaWYgSSBrbm93IHRoZSByZXF1aXJlbWVudHMsIEkgY2FuIGp1c3QgZG8g d2hhdCdzIG5lZWRlZC4gIFllcywgdGhlcmUgYXJlIGlzc3VlcyBhYm91dCB3aGV0aGVyIHRoYXQn cyByZWFsbHkgcHJhY3RpY2FsIG9yIG5vdC4NCg0K From nobody Wed Jan 11 12: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 021EC12956F for ; Wed, 11 Jan 2017 12:19:49 -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 ZJJgHgB7N61M for ; Wed, 11 Jan 2017 12:19:47 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB17E128B38 for ; Wed, 11 Jan 2017 12:19:47 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id w75so83064225ywg.1 for ; Wed, 11 Jan 2017 12:19:47 -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=tyS7GV1gWnzneyWLvbclKGEL7hLHqvCSSiU+NREeNO8=; b=zan00JArscY4OI+eKUrxf77L/lJLwtsAZ1pqqGmaqns5SYv+vmjTkHWgU1k4y6ZAlv GW6SBTqdbROBAS9IEte97/CsHCcuBS0ABUpMNhhzEsa8YvMEc+8DVJ/YYtV2XLF9AU5A KT16VOYLZUYEk872ZShnKga3tZ+9+Zjw20dNw+nxC/MxJhathUvitccye3Yh03vSY0wF yCdBXbJ5oFbwgs2NpXeCMFzRbQQBIEBCros/HVGz1Xku8/XD4bfSoJtNfsRG9Kb6Uqz6 pB/uIZynqWarLmNq6MwiwanhePHVetjvR0SKJs05N+pnipiwrdPDV4rw+XexaExKD0iJ itlw== 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=tyS7GV1gWnzneyWLvbclKGEL7hLHqvCSSiU+NREeNO8=; b=sItCMXLLrWkeRBVYqlyoYjO0Ebkalzhfhzm1TZka04re4HstITeax969Mbz9hbgtJf jApKQHl3RTKbsHdRN7zanHxD8V+emJGaSOgHXzlA0wCz6XLkJ5PRfibFPI5SElKgH9Jh F9xpn0dw07lMIIzqI+jlF3zjaqD9V74kNnccDrSXCOaaEbn+FVjnhVuFO4whOzuC4952 OmMTsragzoVLu7mtJVQM1A8purGx+7914OK0A6fkecHnyzchYo+Wfxw1e3pOOt4KLM2i 28wXKHVPGdtcnJs6RJIzX20RBBveZte1LJBvKQA6zZzTsPRwvuDnKh8WGwghT/mGRuTo 8jWA== X-Gm-Message-State: AIkVDXLaW4nDV2omMfZ10HOtwC+tQqdKO9gtwDSPBowdmIBlJK+j1k+Kco+xZH+/7Ao9QKg4droYbjasqmrgAA== X-Received: by 10.129.125.6 with SMTP id y6mr8530842ywc.234.1484165986834; Wed, 11 Jan 2017 12:19:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Wed, 11 Jan 2017 12:19:06 -0800 (PST) In-Reply-To: <6518fb235c87465a82f8382a595ed976@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6518fb235c87465a82f8382a595ed976@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Wed, 11 Jan 2017 12:19:06 -0800 Message-ID: Subject: Re: Using different crypto To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114948286f23880545d752b3 Archived-At: Cc: Mike Bishop , Ted Hardie , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:19:49 -0000 --001a114948286f23880545d752b3 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2017 at 12:04 PM, Salz, Rich wrote: > > I basically agree with McManus here. > > Mozilla group-think :) > What can I say, we're right-thinking. -Ekr > > > > Another reason why I prefer #2 is that it might enabled "stripped > down" TLS stacks that are optimized > > > only to support QUIC. That seems like a good thing to be able to do, > e.g., for IoT. > > > I'm sorry, I'm not following this. Certainly that would be a good thing, > but I'm not seeing how an > > abstraction layer helps here. What you need there is a profile of TLS. > > Because the abstraction is really a requirements layer, as Mike said. > Therefore if I know the requirements, I can just do what's needed. Yes, > there are issues about whether that's really practical or not. > > --001a114948286f23880545d752b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 11, 2017 at 12:04 PM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
> I bas= ically agree with McManus here.

Mozilla group-think :)

What can = I say, we're right-thinking.

-Ekr
= =C2=A0

> >=C2=A0Another reason why I prefer #2 is that it might enabled &quo= t;stripped down" TLS stacks that are optimized
> > only to support QUIC.=C2=A0 That seems like a good thing to be ab= le to do, e.g., for IoT.

> I'm sorry, I'm not following this. Certainly that would be a g= ood thing, but I'm not seeing how an
> abstraction layer helps here. What you need there is a profile of TLS.=

Because the abstraction is really a requirements layer, as Mike said= .=C2=A0 Therefore if I know the requirements, I can just do what's need= ed.=C2=A0 Yes, there are issues about whether that's really practical o= r not.


--001a114948286f23880545d752b3-- From nobody Wed Jan 11 12:20: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 E9F28128B38 for ; Wed, 11 Jan 2017 12:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 6dU0uplZYroY for ; Wed, 11 Jan 2017 12:20:51 -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 E9FF8129689 for ; Wed, 11 Jan 2017 12:20:50 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id l19so31772544ywc.2 for ; Wed, 11 Jan 2017 12:20:50 -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=WSeZES0eIN3iDMqd4VW6UtcDlOefRMvRkg7gkyGbBVc=; b=p6lFC+uiiFlycUgj0A8HxalCXyMIHU3oQjyyU/4MhflrsYcnE62gpcn/GV6+A73hTZ 3MT8GXyvxyA61sJGSJSk3qtG06YWWN3IQoD/xxSW8Ix5kOQcLr9+6glBq2Dg2FDx37J6 ynaRCU3MtSJe/AxFrOKe5Y9sxkK0fERyDfufqQx6IyzQcGbRo6+7DuekTGis50AcZ3kr 4+EAqVGBE6YHsVRGun5m5g+d1bab9pda5OYwFyVxMA50/YvMv2+Fv51ocHJZdZ6gx4Cq 5e02U/OyOXFxmB61DskpnZstCJhgE+fa2eVXQAESSJDjCtM93g9erAfeNMFc6wn8LgkP +JXg== 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=WSeZES0eIN3iDMqd4VW6UtcDlOefRMvRkg7gkyGbBVc=; b=pNUkHrpWqN5mdKzyk50AqbrvJl9NpS2/pJL/Yo6XOL1yopY+Osf08NfMswoMO/FSDA LVuHZD8TEh1cGV03iacGAvH0lvbk5nGwhGNUJt2T+cyohAWhPvINT4acFDICbgU7mvN7 vyk7vozLRT6QhwROdy3YcsEmHSQ9VOipUmCXDi31uAftjGLjjPxL/XOinKKvS8WfH6S8 abNoFkVkestWfej2P9iWYkmRpJNewXBg5nU8h1+p1ju1MMOJRb/a3yu0wbU1jdjbQ9vb ldSNk3oG5TJYMpTvsp0G2FRj+pUjOiHpf+GKs10FR3HQvaa6BQLLfrXZTnhAsa0oH1sX LIYw== X-Gm-Message-State: AIkVDXIXScQgJU59gktWcY4BmC+SCpnojYfItzq9RaBVyXgjJMgBKQg9+C1mZJmyv+lJoPxb/QkIljltvSwYa2I9 X-Received: by 10.129.90.134 with SMTP id o128mr9435913ywb.63.1484166049993; Wed, 11 Jan 2017 12:20:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Wed, 11 Jan 2017 12:20:29 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Wed, 11 Jan 2017 15:20:29 -0500 Message-ID: Subject: Re: Using different crypto To: Patrick McManus Content-Type: multipart/alternative; boundary=001a114922e233642d0545d75605 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:20:53 -0000 --001a114922e233642d0545d75605 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2017 at 2:23 PM, Patrick McManus wrote: > Folks interested in this who aren't reading the github comment traffic > (highly recommended fwiw) will find https://github.com/quicwg/ > base-drafts/pull/122 useful reading. > > To me this largely boils down to whether we want to add a crypto > negotiation mechanism or just tie it to the transport versioning. I think > in a practical sense what we have (transport versioning) is sufficient and > makes it much easier to feel confident and reason about version 1. (That > would be support for option 1.) > I think making a QUIC version indicate crypto and QUIC RFC at once is fine. However, that doesn't mean the QUIC transport doc has to depend upon the TLS mapping doc. I would think that we can just swap "TLS 1.3" for "Crypto handshake" in all places it occurs and have the RFC make sense. If others think this is infeasible, it'd be helpful to have examples of why. Re: Martin's Duke's question of having many versions at once or mostly the latest-greatest, I would hope that most QUIC users would be on the latest greatest, but as with TLS, there will be users on older versions for some time. > > -Patrick > > > > > On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich wrote: > >> > So, I personally prefer the second style. That's partly because we may >> someday have other crypto protocols, but mostly because it means that when >> TLS evolves an updated RFC describing how to use the new facilities doesn't >> need to update the transport document. >> >> Another reason why I prefer #2 is that it might enabled "stripped down" >> TLS stacks that are optimized only to support QUIC. That seems like a good >> thing to be able to do, e.g., for IoT. >> > > --001a114922e233642d0545d75605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 11, 2017 at 2:23 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
= Folks interested in this who aren't reading the github comment traffic = (highly recommended fwiw) will find https://github.com/quicwg/base-d= rafts/pull/122 useful reading.

To me this= largely boils down to whether we want to add a crypto negotiation mechanis= m or just tie it to the transport versioning. I think in a practical sense = what we have (transport versioning) is sufficient and makes it much easier = to feel confident and reason about version 1. (That would be support for op= tion 1.)

I think making a QUIC = version indicate crypto and QUIC RFC at once is fine.=C2=A0 However, that d= oesn't mean the QUIC transport doc has to depend upon the TLS mapping d= oc.=C2=A0 I would think that we can just swap "TLS 1.3" for "= ;Crypto handshake" in all places it occurs and have the RFC make sense= .=C2=A0 If others think this is infeasible, it'd be helpful to have exa= mples of why.

Re: Martin's Duke's question= of having many versions at once or mostly the latest-greatest, I would hop= e that most QUIC users would be on the latest greatest, but as with TLS, th= ere will be users on older versions for some time.



-Patrick



<= /span>

On Wed, Jan 11, 2017 at 2:07 PM, Salz, R= ich <rsalz@akamai.com> wrote:
> So, I personally prefer the second style.=C2=A0 That's pa= rtly because we may someday have other crypto protocols, but mostly because= it means that when TLS evolves an updated RFC describing how to use the ne= w facilities doesn't need to update the transport document.=C2=A0

Another reason why I prefer #2 is that it might enabled "stripp= ed down" TLS stacks that are optimized only to support QUIC.=C2=A0 Tha= t seems like a good thing to be able to do, e.g., for IoT.


--001a114922e233642d0545d75605-- From nobody Wed Jan 11 12:22: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 5A475128B38 for ; Wed, 11 Jan 2017 12:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 TLUaz-VzU7wZ for ; Wed, 11 Jan 2017 12:22:52 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C0712956F for ; Wed, 11 Jan 2017 12:22:52 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cRPQ3-00071w-2o for quic@ietf.org; Wed, 11 Jan 2017 21:22:51 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cRPPo-0003IL-Th for quic@ietf.org; Wed, 11 Jan 2017 15:22:50 -0500 Received: (qmail 11427 invoked from network); 11 Jan 2017 20:22:35 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.42.52]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jan 2017 20:22:34 -0000 From: "Christian Huitema" To: "'Salz, Rich'" , "'Eric Rescorla'" , "'Patrick McManus'" References: <6518fb235c87465a82f8382a595ed976@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <6518fb235c87465a82f8382a595ed976@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 11 Jan 2017 12:22:30 -0800 Message-ID: <01b801d26c48$70521b80$50f65280$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG1hUIIldZjOV7tI4f6qmdZ6NS/ogK91yg4AhFYp6UBvxUqXAIPV/nxAX895IChHJ6+0A== Content-Language: en-us Subject: RE: Using different crypto X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.38) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrN5wUEqaWJ/v4YsLrPJXBZRcOb18WfxGyg6Om6u4YYm+mQtsYgubPc0yBt eG650ps5hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aIhQRCdMNhge1Unb77YyuZq7B1ZiFqBoajAyTmgSFop97RBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYnxsKeex0DTc6z4W6mGX91geYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8tEzDd JFEeZx0L8qYzBLK5yNBqLkXGaznuCfaQ1w/JpOE= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'Mike Bishop' , 'Ted Hardie' , 'IETF QUIC WG' , 'Martin Thomson' , 'Jana Iyengar' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Jan 2017 20:22:54 -0000 > Because the abstraction is really a requirements layer, as Mike said. = Therefore if I know > the requirements, I can just do what's needed. Yes, there are issues = about whether that's > really practical or not. The abstraction also facilitates modular code development and testing. = For example, developers could use a trivial crypto layer during tests, = so they can test the protocol logic without having a dependency on TLS = stack. Then, they can slide in the TLS stack of their choice, without = changing the transport code. -- Christian Huitema From nobody Wed Jan 11 13:28: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 3FF861294F0 for ; Wed, 11 Jan 2017 13:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GuO1R6wBsT-z for ; Wed, 11 Jan 2017 13:28:44 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E011294EB for ; Wed, 11 Jan 2017 13:28:44 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id 11so649373qkl.3 for ; Wed, 11 Jan 2017 13:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rSZAlwGE3hbsUDfA7lF2sq1guvGAkNfsOmeDPfVD2FE=; b=jyYQKGhYvPrCDWvZEdTSA6AeB+FZMBp1LFm5hG/6JFkrLyeKtsKtleTq6qpHt8iWqt oiKK5sTcEvlfU+wcypvStZ/a3VlQUZAbEsxy/dZuyLKJFQuoa1/EGbeF3Vkw+rDPkcxC 9NNls7MKSDvtCNUr3bDTV5JCdrKnAxkf83s9d5Tydlzz5pn3l1/f2z8APiuM5nConJJD MyJuFg49N2Ms+3By2SljLq0HIgNUkZ14uUnIDFehWqRC+eJNUTROItUoi4bmIg2XS+3y FgH+YtmvBjq80kvUo6K1cOi4eA2YtGR8DoIRByThAzodShjeCeQ041A1QusUn1YWo3qR Zk9A== 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=rSZAlwGE3hbsUDfA7lF2sq1guvGAkNfsOmeDPfVD2FE=; b=INc51IB1g99Exif+FF5SdjDyeOR9vw2pRbuyAtXEt/vWqYYIn68FSzy+073g3UR0q7 ss22EV4PJA8P3Qf/lADISh3j0KzP2LzZtI69CjaiGoYqMV+5mj191QGqjY6wo5eLaQzS VumsRHkSYdw8MeLQmQ2LoDPBbiLdizSLvrPSNpvTJHDYG8iCRRwtF4TWYJEf+7cNTZna DR3I86fFKyQV7SAUA17cOU1W2N73j9R9Z2IpOyNmHvLc7xFCo7ns7VxRoSf26U3HTtYS ae4YXVRQoWYHHhHzuebNmH+337mbzCR/4UilRX/fgvHy97Y/LQPuaYynmp4ngziZX1Fr +gMw== X-Gm-Message-State: AIkVDXLPfeuCXm9ehBfHYaacvniUXMeue00kxarGNKc3+jqhz9InpR/MX2gmrlhiLZc9QBkuwPn+4bGTEc/HDw== X-Received: by 10.55.101.82 with SMTP id z79mr10131649qkb.68.1484170123258; Wed, 11 Jan 2017 13:28:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 11 Jan 2017 13:28:42 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 12 Jan 2017 10:28:42 +1300 Message-ID: Subject: Re: Using different crypto To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:28:45 -0000 On 12 January 2017 at 09:20, Ian Swett wrote: > I think making a QUIC version indicate crypto and QUIC RFC at once is fine. > However, that doesn't mean the QUIC transport doc has to depend upon the TLS > mapping doc. I would think that we can just swap "TLS 1.3" for "Crypto > handshake" in all places it occurs and have the RFC make sense. If others > think this is infeasible, it'd be helpful to have examples of why. I suggest that you read PR 122 and - critically - PR 120 for concrete reasons why this isn't as simple as you are making out. From nobody Wed Jan 11 14:09: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 CE733129522 for ; Wed, 11 Jan 2017 14:09:20 -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 zOKlPaimxohs for ; Wed, 11 Jan 2017 14:09:19 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 099041294E7 for ; Wed, 11 Jan 2017 14:09:19 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id x49so1540505qtc.2 for ; Wed, 11 Jan 2017 14:09: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:content-transfer-encoding; bh=F6lntbyyOEIP5qe4q90v6xGLlcCTdufBiQbtH63TiU0=; b=JgKRijnf1Xb25IH5/k1Wc2iL4AXjpxvoK3+tL45Ymof/2K0xwuh4TnmudPLRESjEmY TrwXBCCSAuxNIIS1AW1rq3WpCA7w1fBtxuQp7/DM5mW/idXe4vbpDXJhTy9JvbRndECY rv/L91dwtpboeRm3BJEiZdAx0aGpYOk0fAsA+XA9lejXgIjPvEsbL3KcMZ3mQDcL36/+ /02nQs2/h4YTMnJdqC0hmHrDMETo3obSmPLzMCylKUAnRYov5Jlcsl6GUQKWBGIweUYQ jnt7uXlMRt8IW91nPk6SJ3GFLz+VbLXq0hbi1Fd6M8NlquwbaSbYp4hGs1OptKLkAFhT zuNg== 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=F6lntbyyOEIP5qe4q90v6xGLlcCTdufBiQbtH63TiU0=; b=WAS5IsitAOiJGoUFrl2d53wdRLPrVOhlG3IevWQ41k3nr/SP4MJ/AmDs2o0xAWt6ld C0zgO3GBLlcpUJJHRWUYyJddXsoBoi99a9ClkAYZgNZT/WTcH/oQIeu8ZpOFdSjP6b7H 1k9OQs/rLizlDSbizMuqOZd1l8CA+fOyDY+uoagK5wvkCLsngOdCrFWzZtRY/E5Qu1L/ 4UN8lYs66HtAr8lvzBnPUg+8ULEKKZyy5J8U2dT1OZLJCMc7kKRqVuLtxkS/Amvd7Ewz fXPtVMBD+nzGhZUUJm3b7UfCL/QNTg+xe7YeG7G0MFIrxuIuPyeljRBEbJqC2u7CzGWU TvaQ== X-Gm-Message-State: AIkVDXIVAhTX2W7BFaJR/Q3e4OweNy0ftOCtHDE9doVE+003/gJpehbi8p1ZJ3dK/pAYDLOYyvzYdmTVnE29hg== X-Received: by 10.200.57.199 with SMTP id v65mr9813169qte.13.1484172558089; Wed, 11 Jan 2017 14:09:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 11 Jan 2017 14:09:17 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 12 Jan 2017 11:09:17 +1300 Message-ID: Subject: Re: Using different crypto To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:09:21 -0000 I like that people seem to forget engineering basics when it comes to things like this, preferring to let desire for ponies get the better of them. Primarily, talking in terms of abstractions makes writing and understanding the document considerably harder [0]. If you want to see how bad this can be, then think about how you might rewrite PR 120 and 122 in terms of abstractions (I would run the exercise for you, but I would prefer to spend my time getting -01 ready for you to review). Understanding the abstraction and the requirements is valuable, but that's not what is in question. On the contrary, the definition of the abstraction has been made clearer than before. See the overview in the TLS doc [1] or the entire section on the interface [2]. I see this as an editorial question: where do we put the pieces of the protocol and how do we describe them? So then, what do we actually gain by maintaining the abstraction as an editorial construct? Making it easier to kick TLS to the kerb sounds like it could be an advantage. But we won't gain that. Once you have a protocol that meets the requirements, it's easy to write a document that replaces TLS, regardless of how our documents are written now. YAGNI, Martin [0] I can't pretend not to care about the writing part, but hope that we can all agree on the understanding piece. [1] https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#protocol-= overview [2] https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#interface= -to-tls On 12 January 2017 at 07:26, Mike Bishop wro= te: > There=E2=80=99s a document structure decision that needs feedback from th= e WG. We > know that we have a very logical document break between the core transpor= t > and how TLS behaves. The question is how sharp that division needs to be= . > There are two obvious paths here: > > > > Quic-transport depends on quic-tls. A future RFC defining QUIC with a > different crypto protocol would describe the deviations from quic-transpo= rt > required to accommodate the new crypto protocol, and would contain the > equivalent of quic-tls for the alternate security protocol. > Quic-transport defines requirements for the crypto protocol, whatever it = may > be, and specifies an interface. Quic-tls describes how TLS is used to > satisfy those requirements and defines a version of QUIC using TLS. A > future RFC would define how a different crypto protocol could be used to > satisfy the same requirements and establishes a different version number = for > that combination. > > > > At the moment, this is somewhat academic, since TLS is the only crypto > protocol we=E2=80=99re chartered to actually define. However, it affects= how much > quic-transport can =E2=80=9Cknow=E2=80=9D about TLS. For example, the cu= rrent draft has a > section on requirements for the crypto protocol. Various pending PRs > propose replacing this with specific references to TLS. However, there i= s > anecdotal interest in having other crypto protocols in other scenario. > > > > How abstract do we want to be here? From nobody Wed Jan 11 14:42: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 74BD212959D for ; Wed, 11 Jan 2017 14:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT0SEAqOuDQq for ; Wed, 11 Jan 2017 14:42:50 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0102.outbound.protection.outlook.com [104.47.41.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8911E129476 for ; Wed, 11 Jan 2017 14:42:50 -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=5XM1q5JPsOvuhmWcJspXeDKqkUHiMshyuyS4f4u4a54=; b=RuzNtkB50kLR5xhiR8vR8KdOXs7qVfPgCj7ca0GsrecIXdDl1tuxy1eGzpb+bMpHa6JGMb+QGvCDnn4DVXwyyKSSyBQoL2l+CkN5WnzcEt0bIGkgJTIATIjY9wwNd67iwyEIp/5zd0k2+c+gvb8C8RG3cDGXp2tUhSdBhH9d15o= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 11 Jan 2017 22:42:49 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0845.013; Wed, 11 Jan 2017 22:42:49 +0000 From: Mike Bishop To: Martin Duke , Patrick McManus Subject: RE: Using different crypto Thread-Topic: Using different crypto Thread-Index: AdJqwmguSJ5RH5YtRcG/iV7NxHADeQBeJWuAAAC914AAAI/MAAAAqlKAAAYr4GA= Date: Wed, 11 Jan 2017 22:42:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [172.58.40.22] x-ms-office365-filtering-correlation-id: ed5173d2-6af1-4f3a-8d0e-08d43a732b6c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:M7bZj1aTbOjud5qQo/HVthAyDzi+RgvMSkFQkVhiXmuNqSsHRfXI8bF9ErtyE3aiEl+CI8fLmkBPBWgX8QsESG3JWwlqMC4jULvxfab3ktAYPEa+3Sjtn6xr47ZcqA2GueRvx9iJufuYw01PtQRRM98K4X0ir8gZzmOvZ9rh+4R3r4tsX9LtfjZ/yHqzEsC2aOfDLzrvCyFpEuBK/hbbVn85MeYEfC2NqxMuDZTGWKe8F7C15hHoFRDd0B3sxcpSrs2Ax9J9htORFmedVnfryhW2qMTBH66YNF2S0itQ5HDLXhWtWgIpvcDG6nGg/nCcVRBiumFw8om3lf2sW88QDOKaC3HhgusONVcbaDxelH4gE2WodnXprjBn/AMh0BsBFOS0/08b7UzvKJMdmxT2RVtrY3Zt/7oVyGU8vOUDC5XQ3A4REvKzcz/dvp3Pmq2JMwkuXzReKMJivrFBwD+rrVyXUq3K4q+pwmZB4fqfKQU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(189002)(24454002)(377454003)(199003)(77096006)(66066001)(39060400001)(38730400001)(7696004)(33656002)(229853002)(7116003)(81166006)(81156014)(8990500004)(3660700001)(86612001)(8676002)(3480700004)(5005710100001)(10290500002)(8936002)(86362001)(19609705001)(68736007)(54356999)(3280700002)(92566002)(93886004)(99286003)(4326007)(76176999)(74316002)(54896002)(6306002)(6506006)(54906002)(6436002)(606005)(7736002)(2950100002)(7906003)(97736004)(5001770100001)(5660300001)(189998001)(236005)(790700001)(122556002)(102836003)(2900100001)(3846002)(6116002)(10090500001)(50986999)(2906002)(101416001)(55016002)(105586002)(9686003)(106356001)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708C976A380827C6DE2B66C87660BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 22:42:48.8365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: "Salz, Rich" , Ted Hardie , IETF QUIC WG , Martin Thomson , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Jan 2017 22:42:53 -0000 --_000_BN6PR03MB2708C976A380827C6DE2B66C87660BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV04oCZcyBiZSBjbGVhciDigJMgbmVpdGhlciBvZiB0aGVzZSBvcHRpb25zIHByb3Bvc2VzIHRo YXQgdGhlIGNyeXB0byBwcm90b2NvbCBiZSBuZWdvdGlhdGVkIHNlcGFyYXRlbHkuICBJ4oCZbSBh c3N1bWluZyB3ZSBnbyB3aXRoIElhbuKAmXMgc3VnZ2VzdGlvbiB0aGF0IGEgUVVJQyDigJx2ZXJz aW9u4oCdIHJlcHJlc2VudHMgYSBjb21iaW5hdGlvbiBvZiBRVUlDIHRyYW5zcG9ydCBhbmQgY3J5 cHRvIGhhbmRzaGFrZS4gIElmIHdlIHdhbnQgYSDigJxtZW514oCdIGFwcHJvYWNoLCB0aGF04oCZ cyBwb3RlbnRpYWxseSBoYXJkZXIuDQoNClRoZXJl4oCZcyB2ZXJ5IGxpdHRsZSB0ZWNobmljYWwg ZGlmZmVyZW5jZSBoZXJlIOKAkyB0aGVyZSB3aWxsIG5lZWQgdG8gYmUgYSBuZXcgUkZDIGFuZCBh IG5ldyB2ZXJzaW9uIG51bWJlciBpZiBzb21lb25lIHdhbnRzIHRvIHVzZSBhIGRpZmZlcmVudCBj cnlwdG8gcHJvdG9jb2wuICBIb3dldmVyLCBpdCBoYXMgYSBtYWpvciBlZmZlY3Qgb24gZG9jdW1l bnQgc3RydWN0dXJlIOKAkyBpbiBwYXJ0aWN1bGFyLCB0aGF0IC10cmFuc3BvcnQgd291bGQgbm90 IGV4cGxpY2l0bHkgZGVwZW5kIG9uIC10bHMuICBUaGF0IGltcGxpZXMgbW92aW5nIHNvbWUgY29u dGVudCB0aGF0IGN1cnJlbnRseSBleGlzdHMgaW4gLXRscyBpbnRvIC10cmFuc3BvcnQsIGFuZCAo YXMgTWFydGluIGFsbHVkZXMgdG8pIG1ha2UgdGhlIC10cmFuc3BvcnQgZG9jdW1lbnQgYnkgaXRz ZWxmIHBvdGVudGlhbGx5IGhhcmRlciB0byB1bmRlcnN0YW5kLg0KDQpGcm9tOiBRVUlDIFttYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIER1a2UNClNlbnQ6 IFdlZG5lc2RheSwgSmFudWFyeSAxMSwgMjAxNyAxMTo0MyBBTQ0KVG86IFBhdHJpY2sgTWNNYW51 cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBTYWx6LCBS aWNoIDxyc2FsekBha2FtYWkuY29tPjsgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IElF VEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogVXNpbmcgZGlmZmVyZW50IGNyeXB0bw0KDQpJJ20g dW5jbGVhciBhcyB0byBob3cgcGVvcGxlIGVudmlzaW9uIHZlcnNpb25pbmcgaW4gcHJhY3RpY2Uu DQoNCklzIGVhY2ggbm9uLWV4cGVyaW1lbnRhbCBRVUlDIHZlcnNpb24gYSBuZXcgUkZDPyBBcmUg dGhlcmUgbGlrZWx5IHRvIGJlIGxvdHMgb2YgdGhlc2UsIG9yIG9ubHkgYSBoYW5kZnVsIGFmdGVy IG1hbnkgeWVhcnM/IENlcnRhaW5seSwgaWYgVENQIHVzZWQgdmVyc2lvbmluZyByYXRoZXIgdGhh biBvcHRpb24gbmVnb3RpYXRpb24gdGhlcmUgbWlnaHQgYmUgbWFueSBwZXJtdXRhdGlvbnMgb2Yg b3B0aW9ucyB0aGF0IHdvdWxkIHJlc3VsdCBpbiBhIGhpZ2ggdmVyc2lvbiBjb3VudCwgc28gdGhh dCBtaWdodCBwb2ludCB0byBsb3RzIG9mIHZlcnNpb25zLg0KDQpSZWxhdGVkbHksIGFyZSB3ZSBs aWtlbHkgdG8gc2VlIHZlcnNpb25zIGJyYW5jaCBvdXQgaW50byBkaWZmZXJlbnQgdXNlIGNhc2Vz IChRVUlDIGZvciBJb1QsIG9yIHdoYXRldmVyKSwgb3IgcHJldHR5IG11Y2ggaGF2ZSB0aGUgbGF0 ZXN0IHZlcnNpb24gYmUgdGhlIGJlc3QgY29tbW9uIHByYWN0aWNlPw0KDQpTbyBpbiBvcHRpb24g KDEpIHRoYXQgTWlrZSBsYXlzIG91dCwgd2hlbiB0aGUgY3J5cHRvIGhhbmRzaGFrZSBjaGFuZ2Vz IHdlIHdvdWxkIGhhdmUgYSB2ZXJ5IHNob3J0IFJGQyB0aGF0IGRlZmluZXMgUVVJQyB2ZXJzaW9u IDUsIHRoYXQgc2F5cywgImV2ZXJ5dGhpbmcgaXMgdGhlIHNhbWUgYXMgUVVJQyB2ZXJzaW9uIDQg ZXhjZXB0IHRoYXQgdGhlIGhhbmRzaGFrZSB1c2VzIHRoZSBmb28gcHJvdG9jb2wiLiBUaGlzIHdp bGwgZ2V0IHJlYWxseSBjdW1iZXJzb21lIGlmIGRpZmZlcmVudCB2ZXJzaW9ucyBzdXBwb3J0IGRp ZmZlcmVudCB1c2UgY2FzZXMuDQoNCkkgdGhpbmsgaXQgaXMgbXVjaCBsZXNzIHBhaW5mdWwgdG8g bmVnb3RpYXRlIHRoZSBoYW5kc2hha2Ugc2VwYXJhdGVseSAoZS5nLiBvcHRpb24gMikuIE1heWJl IGluIHByYWN0aWNlIHRoYXQgbWVhbnMgd2UgcmVzZXJ2ZSA0IGJpdHMgKG9yIHdoYXRldmVyKSBv ZiB0aGUgdmVyc2lvbiBudW1iZXIgZm9yIHRoZSBjcnlwdG8gaGFuZHNoYWtlLCB3aGlsZSB0aGUg b3RoZXIgMjggYml0cyBjb3JyZXNwb25kIHRvIHRoZSB0cmFuc3BvcnQgUkZDLg0KDQoNCg0KT24g V2VkLCBKYW4gMTEsIDIwMTcgYXQgMTE6MjMgQU0sIFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNA bW96aWxsYS5jb208bWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tPj4gd3JvdGU6DQpGb2xrcyBp bnRlcmVzdGVkIGluIHRoaXMgd2hvIGFyZW4ndCByZWFkaW5nIHRoZSBnaXRodWIgY29tbWVudCB0 cmFmZmljIChoaWdobHkgcmVjb21tZW5kZWQgZndpdykgd2lsbCBmaW5kIGh0dHBzOi8vZ2l0aHVi LmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8xMjIgdXNlZnVsIHJlYWRpbmcuDQoNClRvIG1l IHRoaXMgbGFyZ2VseSBib2lscyBkb3duIHRvIHdoZXRoZXIgd2Ugd2FudCB0byBhZGQgYSBjcnlw dG8gbmVnb3RpYXRpb24gbWVjaGFuaXNtIG9yIGp1c3QgdGllIGl0IHRvIHRoZSB0cmFuc3BvcnQg dmVyc2lvbmluZy4gSSB0aGluayBpbiBhIHByYWN0aWNhbCBzZW5zZSB3aGF0IHdlIGhhdmUgKHRy YW5zcG9ydCB2ZXJzaW9uaW5nKSBpcyBzdWZmaWNpZW50IGFuZCBtYWtlcyBpdCBtdWNoIGVhc2ll ciB0byBmZWVsIGNvbmZpZGVudCBhbmQgcmVhc29uIGFib3V0IHZlcnNpb24gMS4gKFRoYXQgd291 bGQgYmUgc3VwcG9ydCBmb3Igb3B0aW9uIDEuKQ0KLVBhdHJpY2sNCg0KDQpPbiBXZWQsIEphbiAx MSwgMjAxNyBhdCAyOjA3IFBNLCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpy c2FsekBha2FtYWkuY29tPj4gd3JvdGU6DQo+IFNvLCBJIHBlcnNvbmFsbHkgcHJlZmVyIHRoZSBz ZWNvbmQgc3R5bGUuICBUaGF0J3MgcGFydGx5IGJlY2F1c2Ugd2UgbWF5IHNvbWVkYXkgaGF2ZSBv dGhlciBjcnlwdG8gcHJvdG9jb2xzLCBidXQgbW9zdGx5IGJlY2F1c2UgaXQgbWVhbnMgdGhhdCB3 aGVuIFRMUyBldm9sdmVzIGFuIHVwZGF0ZWQgUkZDIGRlc2NyaWJpbmcgaG93IHRvIHVzZSB0aGUg bmV3IGZhY2lsaXRpZXMgZG9lc24ndCBuZWVkIHRvIHVwZGF0ZSB0aGUgdHJhbnNwb3J0IGRvY3Vt ZW50Lg0KDQpBbm90aGVyIHJlYXNvbiB3aHkgSSBwcmVmZXIgIzIgaXMgdGhhdCBpdCBtaWdodCBl bmFibGVkICJzdHJpcHBlZCBkb3duIiBUTFMgc3RhY2tzIHRoYXQgYXJlIG9wdGltaXplZCBvbmx5 IHRvIHN1cHBvcnQgUVVJQy4gIFRoYXQgc2VlbXMgbGlrZSBhIGdvb2QgdGhpbmcgdG8gYmUgYWJs ZSB0byBkbywgZS5nLiwgZm9yIElvVC4NCg0KDQo= --_000_BN6PR03MB2708C976A380827C6DE2B66C87660BN6PR03MB2708namp_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV04oCZcyBiZSBjbGVhciDi gJMgPGk+bmVpdGhlcjwvaT4gb2YgdGhlc2Ugb3B0aW9ucyBwcm9wb3NlcyB0aGF0IHRoZSBjcnlw dG8gcHJvdG9jb2wgYmUgbmVnb3RpYXRlZCBzZXBhcmF0ZWx5LiZuYnNwOyBJ4oCZbSBhc3N1bWlu ZyB3ZSBnbyB3aXRoIElhbuKAmXMgc3VnZ2VzdGlvbiB0aGF0IGEgUVVJQyDigJx2ZXJzaW9u4oCd IHJlcHJlc2VudHMgYSBjb21iaW5hdGlvbiBvZiBRVUlDIHRyYW5zcG9ydCBhbmQgY3J5cHRvIGhh bmRzaGFrZS4mbmJzcDsNCiBJZiB3ZSB3YW50IGEg4oCcbWVudeKAnSBhcHByb2FjaCwgdGhhdOKA mXMgcG90ZW50aWFsbHkgaGFyZGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZeKAmXMg dmVyeSBsaXR0bGUgdGVjaG5pY2FsIGRpZmZlcmVuY2UgaGVyZSDigJMgdGhlcmUgd2lsbCBuZWVk IHRvIGJlIGEgbmV3IFJGQyBhbmQgYSBuZXcgdmVyc2lvbiBudW1iZXIgaWYgc29tZW9uZSB3YW50 cyB0byB1c2UgYSBkaWZmZXJlbnQgY3J5cHRvIHByb3RvY29sLiZuYnNwOyBIb3dldmVyLCBpdCBo YXMgYSBtYWpvciBlZmZlY3Qgb24gZG9jdW1lbnQgc3RydWN0dXJlIOKAkyBpbiBwYXJ0aWN1bGFy LCB0aGF0IC10cmFuc3BvcnQNCiB3b3VsZCBub3QgZXhwbGljaXRseSBkZXBlbmQgb24gLXRscy4m bmJzcDsgVGhhdCBpbXBsaWVzIG1vdmluZyBzb21lIGNvbnRlbnQgdGhhdCBjdXJyZW50bHkgZXhp c3RzIGluIC10bHMgaW50byAtdHJhbnNwb3J0LCBhbmQgKGFzIE1hcnRpbiBhbGx1ZGVzIHRvKSBt YWtlIHRoZSAtdHJhbnNwb3J0IGRvY3VtZW50IGJ5IGl0c2VsZiBwb3RlbnRpYWxseSBoYXJkZXIg dG8gdW5kZXJzdGFuZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YNCjwvYj5NYXJ0aW4gRHVrZTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEphbnVhcnkgMTEsIDIwMTcgMTE6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IFBhdHJpY2sgTWNN YW51cyAmbHQ7cG1jbWFudXNAbW96aWxsYS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJp c2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IFRlZCBIYXJkaWUgJmx0 O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs7IFNhbHosIFJpY2ggJmx0O3JzYWx6QGFrYW1haS5jb20m Z3Q7OyBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBnb29nbGUuY29tJmd0OzsgSUVURiBRVUlDIFdHICZs dDtxdWljQGlldGYub3JnJmd0OzsgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFVzaW5nIGRpZmZlcmVudCBjcnlw dG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSB1bmNsZWFyIGFzIHRvIGhvdyBw ZW9wbGUgZW52aXNpb24gdmVyc2lvbmluZyBpbiBwcmFjdGljZS48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGVhY2ggbm9uLWV4cGVyaW1lbnRhbCBRVUlD IHZlcnNpb24gYSBuZXcgUkZDPyBBcmUgdGhlcmUgbGlrZWx5IHRvIGJlIGxvdHMgb2YgdGhlc2Us IG9yIG9ubHkgYSBoYW5kZnVsIGFmdGVyIG1hbnkgeWVhcnM/IENlcnRhaW5seSwgaWYgVENQIHVz ZWQgdmVyc2lvbmluZyByYXRoZXIgdGhhbiBvcHRpb24gbmVnb3RpYXRpb24gdGhlcmUgbWlnaHQg YmUgbWFueSBwZXJtdXRhdGlvbnMgb2Ygb3B0aW9ucyB0aGF0DQogd291bGQgcmVzdWx0IGluIGEg aGlnaCB2ZXJzaW9uIGNvdW50LCBzbyB0aGF0IG1pZ2h0IHBvaW50IHRvIGxvdHMgb2YgdmVyc2lv bnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJlbGF0ZWRseSwgYXJlIHdlIGxpa2VseSB0byBzZWUgdmVyc2lvbnMgYnJhbmNoIG91dCBpbnRv IGRpZmZlcmVudCB1c2UgY2FzZXMgKFFVSUMgZm9yIElvVCwgb3Igd2hhdGV2ZXIpLCBvciBwcmV0 dHkgbXVjaCBoYXZlIHRoZSBsYXRlc3QgdmVyc2lvbiBiZSB0aGUgYmVzdCBjb21tb24gcHJhY3Rp Y2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNvIGluIG9wdGlvbiAoMSkgdGhhdCBNaWtlIGxheXMgb3V0LCB3aGVuIHRoZSBjcnlwdG8gaGFu ZHNoYWtlIGNoYW5nZXMgd2Ugd291bGQgaGF2ZSBhIHZlcnkgc2hvcnQgUkZDIHRoYXQgZGVmaW5l cyBRVUlDIHZlcnNpb24gNSwgdGhhdCBzYXlzLCAmcXVvdDtldmVyeXRoaW5nIGlzIHRoZSBzYW1l IGFzIFFVSUMgdmVyc2lvbiA0IGV4Y2VwdCB0aGF0IHRoZSBoYW5kc2hha2UgdXNlcyB0aGUgZm9v IHByb3RvY29sJnF1b3Q7LiBUaGlzDQogd2lsbCBnZXQgcmVhbGx5IGN1bWJlcnNvbWUgaWYgZGlm ZmVyZW50IHZlcnNpb25zIHN1cHBvcnQgZGlmZmVyZW50IHVzZSBjYXNlcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBpcyBt dWNoIGxlc3MgcGFpbmZ1bCB0byBuZWdvdGlhdGUgdGhlIGhhbmRzaGFrZSBzZXBhcmF0ZWx5IChl LmcuIG9wdGlvbiAyKS4gTWF5YmUgaW4gcHJhY3RpY2UgdGhhdCBtZWFucyB3ZSByZXNlcnZlIDQg Yml0cyAob3Igd2hhdGV2ZXIpIG9mIHRoZSB2ZXJzaW9uIG51bWJlciBmb3IgdGhlIGNyeXB0byBo YW5kc2hha2UsIHdoaWxlIHRoZSBvdGhlciAyOCBiaXRzIGNvcnJlc3BvbmQgdG8gdGhlDQogdHJh bnNwb3J0IFJGQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDExLCAyMDE3IGF0IDExOjIzIEFNLCBQYXRyaWNrIE1j TWFudXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBtY21hbnVzQG1vemlsbGEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xrcyBp bnRlcmVzdGVkIGluIHRoaXMgd2hvIGFyZW4ndCByZWFkaW5nIHRoZSBnaXRodWIgY29tbWVudCB0 cmFmZmljIChoaWdobHkgcmVjb21tZW5kZWQgZndpdykgd2lsbCBmaW5kDQo8YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMTIyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzEyMjwvYT4gdXNl ZnVsIHJlYWRpbmcuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UbyBtZSB0aGlzIGxhcmdl bHkgYm9pbHMgZG93biB0byB3aGV0aGVyIHdlIHdhbnQgdG8gYWRkIGEgY3J5cHRvIG5lZ290aWF0 aW9uIG1lY2hhbmlzbSBvciBqdXN0IHRpZSBpdCB0byB0aGUgdHJhbnNwb3J0IHZlcnNpb25pbmcu IEkgdGhpbmsgaW4gYSBwcmFjdGljYWwgc2Vuc2Ugd2hhdCB3ZSBoYXZlICh0cmFuc3BvcnQgdmVy c2lvbmluZykgaXMgc3VmZmljaWVudA0KIGFuZCBtYWtlcyBpdCBtdWNoIGVhc2llciB0byBmZWVs IGNvbmZpZGVudCBhbmQgcmVhc29uIGFib3V0IHZlcnNpb24gMS4gKFRoYXQgd291bGQgYmUgc3Vw cG9ydCBmb3Igb3B0aW9uIDEuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+LVBhdHJpY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2Vk LCBKYW4gMTEsIDIwMTcgYXQgMjowNyBQTSwgU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyBTbywgSSBwZXJzb25hbGx5IHByZWZlciB0aGUgc2Vjb25kIHN0eWxlLiZuYnNwOyBU aGF0J3MgcGFydGx5IGJlY2F1c2Ugd2UgbWF5IHNvbWVkYXkgaGF2ZSBvdGhlciBjcnlwdG8gcHJv dG9jb2xzLCBidXQgbW9zdGx5IGJlY2F1c2UgaXQgbWVhbnMgdGhhdCB3aGVuIFRMUyBldm9sdmVz IGFuIHVwZGF0ZWQgUkZDIGRlc2NyaWJpbmcgaG93IHRvIHVzZSB0aGUgbmV3IGZhY2lsaXRpZXMg ZG9lc24ndCBuZWVkIHRvIHVwZGF0ZQ0KIHRoZSB0cmFuc3BvcnQgZG9jdW1lbnQuJm5ic3A7PGJy Pg0KPGJyPg0KQW5vdGhlciByZWFzb24gd2h5IEkgcHJlZmVyICMyIGlzIHRoYXQgaXQgbWlnaHQg ZW5hYmxlZCAmcXVvdDtzdHJpcHBlZCBkb3duJnF1b3Q7IFRMUyBzdGFja3MgdGhhdCBhcmUgb3B0 aW1pemVkIG9ubHkgdG8gc3VwcG9ydCBRVUlDLiZuYnNwOyBUaGF0IHNlZW1zIGxpa2UgYSBnb29k IHRoaW5nIHRvIGJlIGFibGUgdG8gZG8sIGUuZy4sIGZvciBJb1QuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708C976A380827C6DE2B66C87660BN6PR03MB2708namp_-- From nobody Wed Jan 11 14:59: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 47BE51295B2 for ; Wed, 11 Jan 2017 14:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ERPUCsKMB9RL for ; Wed, 11 Jan 2017 14:59:19 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF8C129476 for ; Wed, 11 Jan 2017 14:59:18 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id a20so2983044qkc.1 for ; Wed, 11 Jan 2017 14:59: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=IN3o9h/cbEAeyb48M0gc70agCprhEw5cp9eceEpZXU4=; b=QTqxMSdvU1RrEBWFswMf4nsfuV0JVwjMObhdoyQPgVVEwS9kupkLBbJzkeoJtjXoPr PTSRvlS8x9TqS6SjVbr/YLaZkChcXZ0SuvSlC9WFk/EwbrLSh6k4BdasVTKNrgd4uvCi vxAc6cuwHXeq1z17QmH7RH1U+kyuywqrgmyNr4llEC4mreVo2V22NCCtgKV2Q4mFv5e5 kgvQQLNHfK58vO2iYciJSNZBTXB+A2vri1/yeE50fYOnupCaZMiKxCXLKD0tquWeArui xlIxoWKI1q7MFUZ6RQonQH/NwA1+PznawOigXam5acIBOAnv/U5jf16bE1nLfGKbT47y W+pg== 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=IN3o9h/cbEAeyb48M0gc70agCprhEw5cp9eceEpZXU4=; b=RhY2FSR+u8wcOpJvLZJkjG8fuUXKYVixfhIzPcBDKEj0q3w8LJogrmEhZFczxHIIt5 EEF4HN/OkVXLLLSKfvsUSfBmaqJQ7bkwP+u+qknVWBvvYZpg9udNa5nCiUAMnCylTIs3 HyyueOa0fprcEN4ITNj7zh5QvbScTzZ+ztooermaNCsr3AngviGC51gBPmEPH9MV3ey8 z0Iq7VBKwVcnm7xSeLGTSf4tvk6buKIVvXEwbujPW24h55SBmIilUifBPo76U5Zbzu6c GK1WF2QXUC432dWGVCMpR9Qs5bT9jIdJw4Y69QKp8vbRzdN/UAdHR8KvjxJHykgTTW9E 8p8g== X-Gm-Message-State: AIkVDXL5tRkSQUbY0XFZvGGU1vxqXm/HF8+I/lbgLir+FJ4Jj8mZUxbeJF/ElXPcx4JG3e1esGfH6Ldhkoq6Mw== X-Received: by 10.55.157.17 with SMTP id g17mr11670218qke.122.1484175557995; Wed, 11 Jan 2017 14:59:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.182.66 with HTTP; Wed, 11 Jan 2017 14:58:47 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Wed, 11 Jan 2017 14:58:47 -0800 Message-ID: Subject: Re: Using different crypto To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c06f1b6eb32180545d98c06 Archived-At: Cc: "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:59:21 -0000 --94eb2c06f1b6eb32180545d98c06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2017 at 2:42 PM, Mike Bishop wrote: > Let=E2=80=99s be clear =E2=80=93 *neither* of these options proposes that= the crypto > protocol be negotiated separately. I=E2=80=99m assuming we go with Ian= =E2=80=99s > suggestion that a QUIC =E2=80=9Cversion=E2=80=9D represents a combination= of QUIC transport > and crypto handshake. If we want a =E2=80=9Cmenu=E2=80=9D approach, that= =E2=80=99s potentially > harder. > > > There=E2=80=99s very little technical difference here =E2=80=93 there will = need to be a new > RFC and a new version number if someone wants to use a different crypto > protocol. However, it has a major effect on document structure =E2=80=93= in > particular, that -transport would not explicitly depend on -tls. That > implies moving some content that currently exists in -tls into -transport= , > and (as Martin alludes to) make the -transport document by itself > potentially harder to understand. > > > The other consequence is on what documents need to be opened up when you have a new crypto handshake. If TLS 1.N (or 2.0) has a new handshake, I would prefer a world in which that can get described in a new version of quick-tls, without requiring the transport document get revved at the same time. At most, it should have to update the transport RFC to list the new version, but a scoped registry could avoid even that. That approach avoids the risk of re-hashing everything just because the crypto changed. If that means I want a pony, so be it. Ponies are real animals, not mythical ones; you can get one if you spend the money. Yep, there are real costs to this and to ponies, but it isn't like wishing for a unicorn. More realistically, I don't think this is a high end show pony with a video-chat enabled stable; it's more like a trap pony. It gets a bit of work done, and, while there are certainly alternatives, this one is a pretty well-known quantity.. Two cents, Ted *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Martin Duke > *Sent:* Wednesday, January 11, 2017 11:43 AM > *To:* Patrick McManus > *Cc:* Mike Bishop ; Ted Hardie < > ted.ietf@gmail.com>; Salz, Rich ; Jana Iyengar < > jri@google.com>; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* Re: Using different crypto > > > > I'm unclear as to how people envision versioning in practice. > > > > Is each non-experimental QUIC version a new RFC? Are there likely to be > lots of these, or only a handful after many years? Certainly, if TCP used > versioning rather than option negotiation there might be many permutation= s > of options that would result in a high version count, so that might point > to lots of versions. > > > > Relatedly, are we likely to see versions branch out into different use > cases (QUIC for IoT, or whatever), or pretty much have the latest version > be the best common practice? > > > > So in option (1) that Mike lays out, when the crypto handshake changes we > would have a very short RFC that defines QUIC version 5, that says, > "everything is the same as QUIC version 4 except that the handshake uses > the foo protocol". This will get really cumbersome if different versions > support different use cases. > > > > I think it is much less painful to negotiate the handshake separately > (e.g. option 2). Maybe in practice that means we reserve 4 bits (or > whatever) of the version number for the crypto handshake, while the other > 28 bits correspond to the transport RFC. > > > > > > > > On Wed, Jan 11, 2017 at 11:23 AM, Patrick McManus > wrote: > > Folks interested in this who aren't reading the github comment traffic > (highly recommended fwiw) will find https://github.com/quicwg/ > base-drafts/pull/122 useful reading. > > > > To me this largely boils down to whether we want to add a crypto > negotiation mechanism or just tie it to the transport versioning. I think > in a practical sense what we have (transport versioning) is sufficient an= d > makes it much easier to feel confident and reason about version 1. (That > would be support for option 1.) > > -Patrick > > > > > > On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich wrote: > > > So, I personally prefer the second style. That's partly because we may > someday have other crypto protocols, but mostly because it means that whe= n > TLS evolves an updated RFC describing how to use the new facilities doesn= 't > need to update the transport document. > > Another reason why I prefer #2 is that it might enabled "stripped down" > TLS stacks that are optimized only to support QUIC. That seems like a go= od > thing to be able to do, e.g., for IoT. > > > > > --94eb2c06f1b6eb32180545d98c06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 11, 2017 at 2:42 PM, Mike Bishop <= Michael.Bishop@microsoft.com> wrote:

Let=E2=80=99s be clear =E2=80=93 neither of t= hese options proposes that the crypto protocol be negotiated separately.=C2= =A0 I=E2=80=99m assuming we go with Ian=E2=80=99s suggestion that a QUIC = =E2=80=9Cversion=E2=80=9D represents a combination of QUIC transport and cr= ypto handshake.=C2=A0 If we want a =E2=80=9Cmenu=E2=80=9D approach, that=E2=80=99s potentially h= arder.

=C2=A0

<= /p>

There=E2=80=99s very little technical difference her= e =E2=80=93 there will need to be a new RFC and a new version number if som= eone wants to use a different crypto protocol.=C2=A0 However, it has a majo= r effect on document structure =E2=80=93 in particular, that -transport would not explicitly depend on -tls.=C2=A0 That implies moving some conten= t that currently exists in -tls into -transport, and (as Martin alludes to)= make the -transport document by itself potentially harder to understand.

=C2=A0


The other c= onsequence is on what documents need to be opened up when you have a new cr= ypto handshake.=C2=A0 If TLS 1.N (or 2.0)=C2=A0 has a new handshake, I woul= d prefer a world in which that can get described in a new version of quick-= tls, without requiring the transport document get revved at the same time.= =C2=A0 At most, it should have to update the transport RFC to list the new = version, but a scoped registry could avoid even that.=C2=A0 That approach a= voids the risk of re-hashing everything just because the crypto changed.
If that means I want a pony, so be it.=C2=A0 Ponies are rea= l animals, not mythical ones; you can get one if you spend the money.=C2=A0= Yep, there are real costs to this and to ponies, but it isn't like wis= hing for a unicorn.=C2=A0 More realistically, I don't think this is a h= igh end show pony with a video-chat enabled stable; it's more like a trap pony. It g= ets a bit of work done, and, while there are certainly alternatives, this o= ne is a pretty well-known quantity..

Two cents,

Ted

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke
Sent: Wednesday, January 11, 2017 11:43 AM
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ted Hardie <= ;ted.ietf@gmail.com= >; Salz, Rich <rsalz@akamai.com>; Jana Iyengar <jri@google.com>; IETF QUIC WG <quic@ietf.org>; Martin Thom= son <marti= n.thomson@gmail.com>
Subject: Re: Using different crypto

=C2=A0

I'm unclear as to how people envision versioning= in practice.

=C2=A0

Is each non-experimental QUIC version a new RFC? Are= there likely to be lots of these, or only a handful after many years? Cert= ainly, if TCP used versioning rather than option negotiation there might be= many permutations of options that would result in a high version count, so that might point to lots of versi= ons.

=C2=A0

Relatedly, are we likely to see versions branch out = into different use cases (QUIC for IoT, or whatever), or pretty much have t= he latest version be the best common practice?

=C2=A0

So in option (1) that Mike lays out, when the crypto= handshake changes we would have a very short RFC that defines QUIC version= 5, that says, "everything is the same as QUIC version 4 except that t= he handshake uses the foo protocol". This will get really cumbersome if different versions support different use cas= es.

=C2=A0

I think it is much less painful to negotiate the han= dshake separately (e.g. option 2). Maybe in practice that means we reserve = 4 bits (or whatever) of the version number for the crypto handshake, while = the other 28 bits correspond to the transport RFC.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 11, 2017 at 11:23 AM, Patrick McManus &l= t;pmcmanus@mozill= a.com> wrote:

Folks interested in this who aren't reading the = github comment traffic (highly recommended fwiw) will find https://github.com/quicwg/base-drafts/pull/122 useful reading.

=C2=A0

To me this largely bo= ils down to whether we want to add a crypto negotiation mechanism or just t= ie it to the transport versioning. I think in a practical sense what we hav= e (transport versioning) is sufficient and makes it much easier to feel confident and reason about version 1. (Th= at would be support for option 1.)

-Patrick

=C2=A0

=C2=A0

On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich <rsalz@akamai.com> = wrote:

> So, I personally prefer the second style.=C2=A0= That's partly because we may someday have other crypto protocols, but = mostly because it means that when TLS evolves an updated RFC describing how= to use the new facilities doesn't need to update the transport document.=C2=A0

Another reason why I prefer #2 is that it might enabled "stripped down= " TLS stacks that are optimized only to support QUIC.=C2=A0 That seems= like a good thing to be able to do, e.g., for IoT.

=C2=A0

=C2=A0


--94eb2c06f1b6eb32180545d98c06-- From nobody Wed Jan 11 15:24: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 0D6571295C9 for ; Wed, 11 Jan 2017 15:24:20 -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 m2C1VNNBbDs7 for ; Wed, 11 Jan 2017 15:24:18 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 BB5741295C6 for ; Wed, 11 Jan 2017 15:24:18 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id x49so2988039qtc.2 for ; Wed, 11 Jan 2017 15:24: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=DM5GteElwchdPruVAYu8Ivriqkvo0cNykoiJdaWzpw4=; b=Mo3G0CmecSL/F3HALyRNSGnathXykqVQRnbaxALPraQbBlbzs2GZMkdqUYtwEyRWR+ khG/G7/aD1KUfSlGgqPrTZoIelqGghYibH+vFxbepg5cdaKdbt8YbNf8++M58rTNSi0I vpliBNLbkv1o2CihbOoodfNN9UiHg8rYGhZByMbEC2iar5juaQfgAoyks2sOs/7gHO90 OLf45pOc+5ZMIAiBdab+WRtyV86neenC7cNt4rIE+t6hRtkiDnjHYneu3MQymWE1J03F kjekp9uaB5W7sor6U73Q7U4fmnpXigbVErGrVvjIP54dRomblLLA7lK2EVY4zLQ2dDWE kV5w== 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=DM5GteElwchdPruVAYu8Ivriqkvo0cNykoiJdaWzpw4=; b=TB6/j8TK026J5NlgliQA1laXF5KlDicOAcPzf2eo+5z/OtSEuncOfepftumlA5DQAm NWZdvp0yFnGQr6JFwkMaJCHPJShj5IyMR2GAkeKuKDBQlXKdWOQXuxusNB8gIry9sYSw bySd6PWYcuWJn/JhaTVmrmU08UMdBI+sf6dzLz2lSvSd+kXAtvORXZxh3ZgKwFkiNUBn CQkGroqx63X1tYOaWS9jquOD+RRqK4mCZAnu8dyWkJpTMJ8I4qBaWj8zI4em2H0VTZp0 Oj57tbygE4XFZBUeWRqLsM49zccLhC0slVpCppavfV1Lk+6keJ0+sumWPAOi4Ji6jmxA 27zA== X-Gm-Message-State: AIkVDXIXqOhqPCuxTdo5YTVRzl9av+9eXPWIRvgv+RsL5VPZUqugfd9lpUDNIIGaTI7XAgfsioK86eQOp/fRtw== X-Received: by 10.237.35.84 with SMTP id i20mr11333561qtc.247.1484177057925; Wed, 11 Jan 2017 15:24:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 11 Jan 2017 15:24:17 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 12 Jan 2017 12:24:17 +1300 Message-ID: Subject: Re: Using different crypto To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:24:20 -0000 On 12 January 2017 at 11:58, Ted Hardie wrote: > If TLS 1.N (or 2.0) has a new handshake, I would prefer a world in which > that can get described in a new version of quick-tls If we go with https://github.com/quicwg/base-drafts/pull/138 then TLS N won't require changes to any document. Rather than continue to beat about the bushes - we're unlikely to find any actual ponies there - let's ask the real question. You only plan to replace something if you plan to replace it: do you want to replace TLS? And why? From nobody Wed Jan 11 15:41: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 69F50129542 for ; Wed, 11 Jan 2017 15:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 RIHrx0Q2p7tt for ; Wed, 11 Jan 2017 15:41:27 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1829D129476 for ; Wed, 11 Jan 2017 15:41:27 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id 3so4464976oih.1 for ; Wed, 11 Jan 2017 15:41:27 -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=eoxew3RQ80K/SNxItyr1p7knyi2E0FopoNgJ3uig9pA=; b=I04bsbAI7ORXYxz1Tw6IrDNwnIFEzYpBSxij6l8USiK1NZMkfR95IJ8M3fs/nROpHS TpVDnnDfrENNZoj5adBWriTExfOuFTINCHkdfcC8Xaz/Fq9N1NNuopzS8+G1YZA9qm7t 3hAXJHf1lk8jaFjzkKsHQGpKlEO9TtqLY1vTC9Y2KUSu1VAkKGbF9h4O3rKbDLkt9ZNu 0I+6mT72hR6NueE4Iby3ya32jE00Sb2h1poSLRqMIai52By0qYa7cn7PrfDOKPutMWPc qnFONOhUqMBLrmZu7/5JuPaAE/IhxliiqL9TJygYoYwo087qqGy3kVN0zFP31GPPqMud c+3A== 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=eoxew3RQ80K/SNxItyr1p7knyi2E0FopoNgJ3uig9pA=; b=ZRjT5BnK2sfbN/XdKaf6NeECkzA5q0MhjTEkp99A30KBG03UdJ1LCH5qsST8NJX3V2 HWdP3p9XsLmN+gUNMAUAiOx5WTKuH/DyUpZ5E9WfF2G08iATXTPlpb99MuYO9u+O7BfQ 8IVImCnAloyKjzj5mheUcvsehDgCsZ08WaGrog7jdyXIMak3MaE9B52LPYd9w7ZbJmh+ sHdwqiLOaVl3IzCEVNpmJdydADT6phnEI/sQ1UlvGdz6tiQB3FoP7YsE8CRxJgRM4v/4 W2EZ5bezFH3J8RmoPysrU9pRYXYyia08w6Ejt7uu2x3dUosTkreSAQ3zWzLBXWcEuiVN 5D8A== X-Gm-Message-State: AIkVDXJ+szOzn4/m7SCaK8zaOz0PpdqraAO0NJb41S2wK8i47/l4ooL/xydhSQtVZsh68yN/dAz5Mi0fiAk+UQ== X-Received: by 10.202.195.144 with SMTP id t138mr5634516oif.142.1484178086491; Wed, 11 Jan 2017 15:41:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.38.251 with HTTP; Wed, 11 Jan 2017 15:41:25 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 11 Jan 2017 15:41:25 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113521dea0fb6f0545da2333 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:41:28 -0000 --001a113521dea0fb6f0545da2333 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2017 at 3:24 PM, Martin Thomson wrote: > On 12 January 2017 at 11:58, Ted Hardie wrote: > > If TLS 1.N (or 2.0) has a new handshake, I would prefer a world in which > > that can get described in a new version of quick-tls > > If we go with https://github.com/quicwg/base-drafts/pull/138 then TLS > N won't require changes to any document. > > Rather than continue to beat about the bushes - we're unlikely to find > any actual ponies there - let's ask the real question. You only plan > to replace something if you plan to replace it: do you want to replace > TLS? And why? > (1) The most likely scenario I can think of is a desire for a lighter (or nonexistent!) crypto regime for applications that don't care that much about security. I know SSL-everywhere is an article of faith for many people, but there are also applications where messing around with certificates is way more trouble than it's worth (ietf.org doesn't use TLS :-)). Whether that is a valid future use case for QUIC is debatable, but that's the most likely reason to move from TLS. (2) Some sort of out-of-band key agreement. (3) Perhaps people who know more about crypto than me can think of a situation (quantum computing?) where TLS is fundamentally inappropriate. --001a113521dea0fb6f0545da2333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 11, 2017 at 3:24 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 12 January 2017 at 11:58, Ted Hardie <ted.ietf@gmail.com> wrote:
> If TLS 1.N (or 2.0)=C2=A0 has a new handshake, I would prefer a world = in which
> that can get described in a new version of quick-tls

If we go with https://github.com/quicwg/ba= se-drafts/pull/138 then TLS
N won't require changes to any document.

Rather than continue to beat about the bushes - we're unlikely to find<= br> any actual ponies there - let's ask the real question.=C2=A0 You only p= lan
to replace something if you plan to replace it: do you want to replace
TLS?=C2=A0 And why?

(1) The most likely= scenario I can think of is a desire for a lighter (or nonexistent!) crypto= regime for applications that don't care that much about security. I kn= ow SSL-everywhere is an article of faith for many people, but there are als= o applications where messing around with certificates is way more trouble t= han it's worth (ietf.org doesn't us= e TLS :-)).

Whether that is a valid future use cas= e for QUIC is debatable, but that's the most likely reason to move from= TLS.

(2) Some sort of out-of-band key agreement.<= /div>

(3) Perhaps people who know more about crypto than= me can think of a situation (quantum computing?) where TLS is fundamentall= y inappropriate.

--001a113521dea0fb6f0545da2333-- From nobody Wed Jan 11 17:42:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF12129458 for ; Wed, 11 Jan 2017 17:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 kKeFhDAhIU7N for ; Wed, 11 Jan 2017 17:42:02 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF1A129454 for ; Wed, 11 Jan 2017 17:42:02 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id 96so4118173uaq.3 for ; Wed, 11 Jan 2017 17:42:02 -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=NKCqOLpQxwCYxymuYrB3PFHfXq74ZOqNnqmktVeOuuM=; b=gXe22yyn0PPLntDiMRyRI2Ge/LXW2cCT2G7hT3e8Ags882msdriE5fQ4rVyK+EeYKa UgRuLYcg1Ta4JvBqV69gOzM8muf2mUoWqcWeKOmnhcy+CCekny3QXqZzoowEkGXuP4GX DYPem0U6+b4Vesub9/PtzDuMgLK5XrN4N8vOzMeu3/cXvooTH8Xe+LyVYEqse+Wioa88 KY3QgtdPbY2C1Sb9Bqni4TXPqQpmHX0Znfj9Ye5UQhzjLBRfzAEpYU56doB//CsNb+yB Q68Tia9+jRJJ6VUb8ob9Cx87abnlzHrXNbNsKJapG1XLyzMhvCTwMkSF8+niQdigP4kW WcYw== 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=NKCqOLpQxwCYxymuYrB3PFHfXq74ZOqNnqmktVeOuuM=; b=oeuckqYTug/Seh4a+jqwcAOynqB4yqeaf/WJKEuudbL/AH3VH9+e7xME2mLaf7K0IK Pgy1Zwpe88ht+EVorkB6ObsizyivqWj9IARjsyjzXNnBLA4ZVGXWrnOPjuotyDKWWl+2 n0T+eBwP2mm+Klk3eNZwewLoDd/W97O45dvxeANCYFMQga53SEZ9IbYrqeORJW/cbFCj Vv8xa6Dk9w7/eUnqtLyKPPrYuqoizXDp81VPWnlHuMP85Xv97DBD7BvtIO8ZGEU1aJE7 pI4471Zq2HNHyTs1q1YHsCa2Q6E7cysTZUiKa5qjy4eJHZbg3hT6MolnAjcUqi0QzqZl 03Xw== X-Gm-Message-State: AIkVDXKKTL1LiXXTntgpwZXDRiPX8aRlQWVrYXjrBZxKkhUC3N9k1ha/Y000/cprj5syqrovjm4cP2DM5uMoyB4j X-Received: by 10.159.37.1 with SMTP id 1mr6395897uaz.2.1484185321309; Wed, 11 Jan 2017 17:42:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 17:42:00 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 17:42:00 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c122e4cdbe0360545dbd247 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:42:04 -0000 --94eb2c122e4cdbe0360545dbd247 Content-Type: text/plain; charset=UTF-8 (Just catching up on this thread.) Addressing the editorial: The original goal in my mind was to have an abstract interface in the transport doc, and I've wanted to fill out the "Crypto Requirements" section to actually define the right interface. I'm still in favor of keeping TLS out of the transport doc, and I'm happy to work on text to make it happen. I don't want to belittle the writing issue here -- I spent many hours on splitting the parts of QUIC into pieces -- I think it's important enough that I'm willing to spend more hours trying to keep those pieces separate. If we assume TLS in the transport doc now, there will be all sorts of TLS-creep, making it that much harder to change it later. FWIW, it's not just modularity for the sake of it, but the "right" kind of modularity that's let us do integration of crypto with transport while allowing us to replace QUIC crypto in the Google QUIC implementation with TLS. There's no reason to not allow a handshake that an application bundle decides to use. Addressing the understanding: The -00 drafts are structured in a way as to say that HTTPS requires QUIC with TLS. HTTPS using QUIC requires TLS, and a different application using QUIC might use non-TLS. I don't imagine that HTTPS is going to require anything but TLS, but that's not the case if we're leaving QUIC open to other applications (which we are.) Baking TLS into the transport draft means that a new application that wants to use QUIC but not TLS will have to (i) define an application mapping doc and (ii) change the transport doc. That hardly seems sensible. I'm not sure I follow the logic for combining QUIC and TLS versions as well -- I expect that TLS version negotiation will happen on Stream 1 as per its state machine. Why is this an issue? - jana On Wed, Jan 11, 2017 at 3:24 PM, Martin Thomson wrote: > On 12 January 2017 at 11:58, Ted Hardie wrote: > > If TLS 1.N (or 2.0) has a new handshake, I would prefer a world in which > > that can get described in a new version of quick-tls > > If we go with https://github.com/quicwg/base-drafts/pull/138 then TLS > N won't require changes to any document. > > Rather than continue to beat about the bushes - we're unlikely to find > any actual ponies there - let's ask the real question. You only plan > to replace something if you plan to replace it: do you want to replace > TLS? And why? > --94eb2c122e4cdbe0360545dbd247 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Just catching up on this thread.)

Addr= essing the editorial: The original goal in my mind was to have an abstract = interface in the transport doc, and I've wanted to fill out the "C= rypto Requirements" section to actually define the right interface. I&= #39;m still in favor of keeping TLS out of the transport doc, and I'm h= appy to work on text to make it happen. I don't want to belittle the wr= iting issue here -- I spent many hours on splitting the parts of QUIC into = pieces -- I think it's important enough that I'm willing to spend m= ore hours trying to keep those pieces separate.

If we assume TLS in the transport d= oc now, there will be all sorts of TLS-creep, making it that much harder to= change it later. FWIW, it's not just modularity for the sake of it, bu= t the "right" kind of modularity that's let us do integration= of crypto with transport while allowing us to replace QUIC crypto in the G= oogle QUIC implementation with TLS. There's no reason to not allow a ha= ndshake that an application bundle decides to use.

Addressing the understanding: = The -00 drafts are structured in a way as to say that HTTPS requires QUIC w= ith TLS. HTTPS using QUIC requires TLS, and a different application using Q= UIC might use non-TLS. I don't imagine that HTTPS is going to require a= nything but TLS, but that's not the case if we're leaving QUIC open= to other applications (which we are.) Baking TLS into the transport draft = means that a new application that wants to use QUIC but not TLS will have t= o (i) define an application mapping doc and (ii) change the transport doc. = That hardly seems sensible.

I'm not sure I follow the logic for combining QUI= C and TLS versions as well -- I expect that TLS version negotiation will ha= ppen on Stream 1 as per its state machine. Why is this an issue?

- jana


On Wed, Jan 11, 2017 at 3:24 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 12 January 2017 at 11:58= , Ted Hardie <ted.ietf@gmail.com> wrote:
> If TLS 1.N (or 2.0)=C2=A0 has a new handshake, I would prefer a world = in which
> that can get described in a new version of quick-tls

If we go with https://github.com/quicwg/ba= se-drafts/pull/138 then TLS
N won't require changes to any document.

Rather than continue to beat about the bushes - we're unlikely to find<= br> any actual ponies there - let's ask the real question.=C2=A0 You only p= lan
to replace something if you plan to replace it: do you want to replace
TLS?=C2=A0 And why?

--94eb2c122e4cdbe0360545dbd247-- From nobody Wed Jan 11 17:48: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 30B2E129454 for ; Wed, 11 Jan 2017 17:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyyi69mi891n for ; Wed, 11 Jan 2017 17:47:57 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80BD21293F9 for ; Wed, 11 Jan 2017 17:47:57 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u25so6138483qki.2 for ; Wed, 11 Jan 2017 17:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pqlQViNPJ2m/Ar6oO/5KouGZDOMkMd+stjn0q4WXl2s=; b=othMcbJLzOy+ZIBidQr+U4740be1lQWgm4p8vivGA/m30BrwUB5KWsNR4bkXypi7gV 45fZqW+vfg5pWZdsQIsMDW3tdSpZwZjSWbj6FSauox8aEC4WethA3Zgg9S3I3IBXUcoa 65ubMhXPJvuZYyo/Sh031d9/mQqFoEKE7mT/T0KdbA5a/atqBcOIEU9wIHo4Gv+PUZLp /H+pKOf6lULAB27SuBOmyLX8bs/GuDu0WPJcfFB62EyepS9Wue1MzpaIFBrFD8+i6dSb zZAV2qb7NyEHF0VF8/EBJcb49ckoTdd7dPs2hvCBNyzsmDOlvxGRrz7Gr0mEPKLsSZob wmBQ== 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=pqlQViNPJ2m/Ar6oO/5KouGZDOMkMd+stjn0q4WXl2s=; b=CAPzypVITEIkg6ZIvLatJcQb7kswTR4WLl+4AwZTx/K89Tp952REiHwiGuDbEW5GNj axg8l4azrVdv+grIVvmGLDZ/IteM/enJPgryZnoh3IrsSdFJgvtfcc56c7a5ngZ+dQNf WHOUSNogDoKY58kkvEXZ4lg+f9nIq9s5tPjqmaZYrRPE8KQV16Gv2LLkdduQzMRKAkFY DuyLx6/SEyGOUt+Fu1F/PaA8kHrzT8VUQFQ3tKnbLXS9A28SU1erYFFV0A4QmZtpevql qH6tsTjsdCMc89CVYwVVmcQH/YF+NhjsaBOFRVEqDLNh2HeSgxgPjYFrxI9PbrO3uBrh OQgw== X-Gm-Message-State: AIkVDXIeUgVWYpe0H7coevxALFKgXlOnUfj79xBgEakmFgC5qKxT/ZRe+J/NG6HHcKM1s/4GK96ib51phKjcdw== X-Received: by 10.55.138.2 with SMTP id m2mr10900770qkd.115.1484185676723; Wed, 11 Jan 2017 17:47:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 11 Jan 2017 17:47:56 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 12 Jan 2017 14:47:56 +1300 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:47:59 -0000 On 12 January 2017 at 14:42, Jana Iyengar wrote: > I'm not sure I follow the logic for combining QUIC and TLS versions as well > -- I expect that TLS version negotiation will happen on Stream 1 as per its > state machine. Why is this an issue? I think that the plan was to say that QUIC version 1 uses TLS (any version). From nobody Wed Jan 11 17:48: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 A450E1293F9 for ; Wed, 11 Jan 2017 17:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 BaHznKjwRvC7 for ; Wed, 11 Jan 2017 17:48:27 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 0C5CE129441 for ; Wed, 11 Jan 2017 17:48:27 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id t8so3669660vke.3 for ; Wed, 11 Jan 2017 17:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O8wp0aie/FUMxyHSoQwVZlga3w1R1ppGRc+wz6Fx2gA=; b=GA3PpaJJKNHcyHQiG9TfGTv0JMsPpiP1RY/elkuBvA3A3Tvk9lLdLPXNANmc3kA47d mzTqmIdeTut/HKHv+238HRTa+1eH/WOfXz+jRX1ufgPXzSTnpkF/4S4Fp4fNGBD335fV gxi2b4wU1UoM9g9rSEhVnMXk3Kx5rPw5ow3G1+AetzRh0J3/15/4PoNxASTkjHod8Q3A lVYactt7y+bPajbj3HPQUPk+vy9YLpZG4x1kYCmOQp4zVQp2b7BzXGfaSz8/rRGRAEiO NS/hCSkNSRULgu9fluWqI6ZQXtF4gpijSrrbrkrHO8Y2S8sKMW4+WGeVyV9T6oOXWfl9 mqSQ== 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=O8wp0aie/FUMxyHSoQwVZlga3w1R1ppGRc+wz6Fx2gA=; b=T8d3aTaP8vuwJ1lxxphGk0Fijrur1peGH2L1XumiX2/9xQ/SquuiUptP/dM0cflzSd 4spObynjjKfCpnmueNGNGwD8MuCoBvsAD5i6ecKAe/nGC5LHy7z7NC1Cn/fnDGYrcBSX nlYqquEwLV0sXTm3hnX+NufT02nfYWH9OXh0/DOZqRkfIAWrx5YbXybe8Tl803za58M0 6d4Vt8Sl7WuVeHcjoAyRR9blKG6zjQNP9Lo4ktMJJMdoHhfVTb5684/XEMU1cZrYAwrQ YlgK5HqjXW2yeaV8j39MzAV+omDMJOBf9dL5mZlMCfUQLTnUCX5VE/oZ1gwnkfdPyp/j CUXw== X-Gm-Message-State: AIkVDXI1jKHrj3cxjeSWaiw1WBCkW5wBVHeoPf4b4F28tv6+V8N1+KGl012x+4fruZo9XXH51+12GxcyF/kowgcD X-Received: by 10.31.87.6 with SMTP id l6mr4769531vkb.116.1484185705892; Wed, 11 Jan 2017 17:48:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 17:48:25 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 17:48:25 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e5288c8128c0545dbe9eb Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:48:28 -0000 --001a114e5288c8128c0545dbe9eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Primarily, talking in terms of abstractions makes writing and > understanding the document considerably harder [0]. If you want to > see how bad this can be, then think about how you might rewrite PR 120 > and 122 in terms of abstractions (I would run the exercise for you, > but I would prefer to spend my time getting -01 ready for you to > review). > IIU 120 correctly, this moves the source-address token functionality into TLS. Why's this necessary? The current -00 draft says: " Source Address Spoofing Defense: Since QUIC handles source address verification, the crypto protocol SHOULD NOT impose a separate source address verification mechanism." This leaves the onus on the transport, which is similar to how TLS 1.3 interacts with TFO. - jana > Understanding the abstraction and the requirements is valuable, but > that's not what is in question. On the contrary, the definition of the > abstraction has been made clearer than before. See the overview in > the TLS doc [1] or the entire section on the interface [2]. > > I see this as an editorial question: where do we put the pieces of the > protocol and how do we describe them? > > So then, what do we actually gain by maintaining the abstraction as an > editorial construct? Making it easier to kick TLS to the kerb sounds > like it could be an advantage. But we won't gain that. Once you have > a protocol that meets the requirements, it's easy to write a document > that replaces TLS, regardless of how our documents are written now. > > YAGNI, > Martin > > [0] I can't pretend not to care about the writing part, but hope that > we can all agree on the understanding piece. > [1] https://quicwg.github.io/base-drafts/draft-ietf-quic-tls. > html#protocol-overview > [2] https://quicwg.github.io/base-drafts/draft-ietf-quic-tls. > html#interface-to-tls > > On 12 January 2017 at 07:26, Mike Bishop > wrote: > > There=E2=80=99s a document structure decision that needs feedback from = the WG. > We > > know that we have a very logical document break between the core > transport > > and how TLS behaves. The question is how sharp that division needs to > be. > > There are two obvious paths here: > > > > > > > > Quic-transport depends on quic-tls. A future RFC defining QUIC with a > > different crypto protocol would describe the deviations from > quic-transport > > required to accommodate the new crypto protocol, and would contain the > > equivalent of quic-tls for the alternate security protocol. > > Quic-transport defines requirements for the crypto protocol, whatever i= t > may > > be, and specifies an interface. Quic-tls describes how TLS is used to > > satisfy those requirements and defines a version of QUIC using TLS. A > > future RFC would define how a different crypto protocol could be used t= o > > satisfy the same requirements and establishes a different version numbe= r > for > > that combination. > > > > > > > > At the moment, this is somewhat academic, since TLS is the only crypto > > protocol we=E2=80=99re chartered to actually define. However, it affec= ts how > much > > quic-transport can =E2=80=9Cknow=E2=80=9D about TLS. For example, the = current draft has > a > > section on requirements for the crypto protocol. Various pending PRs > > propose replacing this with specific references to TLS. However, there > is > > anecdotal interest in having other crypto protocols in other scenario. > > > > > > > > How abstract do we want to be here? > --001a114e5288c8128c0545dbe9eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Primarily, talking in terms o= f abstractions makes writing and
understanding the document considerably harder [0].=C2=A0 If you want to see how bad this can be, then think about how you might rewrite PR 120
and 122 in terms of abstractions (I would run the exercise for you,
but I would prefer to spend my time getting -01 ready for you to
review).

IIU 120 correctly, this moves = the source-address token functionality into TLS. Why's this necessary? = The current -00 draft says:
" Source Address Spoofing Defens= e: Since QUIC handles source address
=C2=A0 verification, the cry= pto protocol SHOULD NOT impose a separate
=C2=A0 source address v= erification mechanism."

This leaves the onus = on the transport, which is similar to how TLS 1.3 interacts with TFO.
=

- jana
=C2=A0
Understanding the abstraction and the requirements is valuable, but
that's not what is in question. On the contrary, the definition of the<= br> abstraction has been made clearer than before.=C2=A0 See the overview in the TLS doc [1] or the entire section on the interface [2].

I see this as an editorial question: where do we put the pieces of the
protocol and how do we describe them?

So then, what do we actually gain by maintaining the abstraction as an
editorial construct?=C2=A0 Making it easier to kick TLS to the kerb sounds<= br> like it could be an advantage. But we won't gain that.=C2=A0 Once you h= ave
a protocol that meets the requirements, it's easy to write a document that replaces TLS, regardless of how our documents are written now.

YAGNI,
Martin

[0] I can't pretend not to care about the writing part, but hope that we can all agree on the understanding piece.
[1] https://quicwg.gi= thub.io/base-drafts/draft-ietf-quic-tls.html#protocol-overview
[2] https://quicwg.git= hub.io/base-drafts/draft-ietf-quic-tls.html#interface-to-tls<= br>

On 12 January 2017 at 07:26, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> There=E2=80=99s a document structure decision that needs feedback from= the WG.=C2=A0 We
> know that we have a very logical document break between the core trans= port
> and how TLS behaves.=C2=A0 The question is how sharp that division nee= ds to be.
> There are two obvious paths here:
>
>
>
> Quic-transport depends on quic-tls.=C2=A0 A future RFC defining QUIC w= ith a
> different crypto protocol would describe the deviations from quic-tran= sport
> required to accommodate the new crypto protocol, and would contain the=
> equivalent of quic-tls for the alternate security protocol.
> Quic-transport defines requirements for the crypto protocol, whatever = it may
> be, and specifies an interface.=C2=A0 Quic-tls describes how TLS is us= ed to
> satisfy those requirements and defines a version of QUIC using TLS.=C2= =A0 A
> future RFC would define how a different crypto protocol could be used = to
> satisfy the same requirements and establishes a different version numb= er for
> that combination.
>
>
>
> At the moment, this is somewhat academic, since TLS is the only crypto=
> protocol we=E2=80=99re chartered to actually define.=C2=A0 However, it= affects how much
> quic-transport can =E2=80=9Cknow=E2=80=9D about TLS.=C2=A0 For example= , the current draft has a
> section on requirements for the crypto protocol.=C2=A0 Various pending= PRs
> propose replacing this with specific references to TLS.=C2=A0 However,= there is
> anecdotal interest in having other crypto protocols in other scenario.=
>
>
>
> How abstract do we want to be here?

--001a114e5288c8128c0545dbe9eb-- From nobody Wed Jan 11 17:50: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 7CF241293F9 for ; Wed, 11 Jan 2017 17:50:50 -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 aTUOpB_xgRQv for ; Wed, 11 Jan 2017 17:50:49 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD6C129428 for ; Wed, 11 Jan 2017 17:50:49 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id a20so6315726qkc.1 for ; Wed, 11 Jan 2017 17:50: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=Dj/Vou0oAxzfBSNytAHFKw1mUGfRT0YrHbseyeDB9jA=; b=cYEMFlHoC3n9D8AWJDtjcVHOYcKdilD7Oh697SV+l4OwjrYdK5Tp5br9/xQqQeC7jc hq7DguV7waahU1MqmB2jLNrns3+mXjSqvk3cbzEyn35EGw/fchqF43CHm5AkM5iY3737 ABzENxTy/JwVY1LGnUqsa7PGIBUZt5I8djyACKPBf9L5CsGXlTi58wWUaAMiRmocQIKD PgHJt03TtD7OyPxc3R5Hii6szWFISTc/y6EuLJzFMOJP718zsNQfB/6SLGW0MiThHBk9 YLIdSrb+B9SOHncttw2wJJh+nSLoJhvME02tZq7TBNr5hsjlKUE1QKYnP78HobRLMUyI jArA== 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=Dj/Vou0oAxzfBSNytAHFKw1mUGfRT0YrHbseyeDB9jA=; b=qZ+Cjc81ftmAxOEKLDamCVk46/i80tW8sbk2APArsj2aqtZXXNCzll08jsw2zDAcsf ewqUwKP+oWwe28C5n/4p0orLh+UKcZAa4S05WohyTN+QC76RiTnUUjRzfwaQqyMfW+B+ 2OHMQSNdaBjd2ckjN8tG7WLAGK4lRQMk8IXUrGD8SRhkmMPFF19fpkhtUcBDMiPceNM4 78MpFfFdq6MK5A4mIvRDcTYnuJGhvCy9VKvljeZhvPx/JrGRyzo4Vtotmr/SRk/iKtXm HlRASgWhUbaLKioJcTgoGo15O9+/XIqcKEl63FsVqeMuiMCdGZDtwKbRtLHSiEPWVKA4 CCLg== X-Gm-Message-State: AIkVDXI3apYsM4oNr2B4BM0WEv2jb+ffsQnZeQ5YJNlzvYw06GdutQAHgIOs2xCatmbeKxm7OQsDBHhb9bSRdw== X-Received: by 10.233.235.66 with SMTP id b63mr12149304qkg.144.1484185848566; Wed, 11 Jan 2017 17:50:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 11 Jan 2017 17:50:47 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 12 Jan 2017 14:50:47 +1300 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:50:50 -0000 On 12 January 2017 at 14:48, Jana Iyengar wrote: > IIU 120 correctly, this moves the source-address token functionality into > TLS. Why's this necessary? The current -00 draft says: > " Source Address Spoofing Defense: Since QUIC handles source address > verification, the crypto protocol SHOULD NOT impose a separate > source address verification mechanism." > > This leaves the onus on the transport, which is similar to how TLS 1.3 > interacts with TFO. Well, there we have a problem: QUIC doesn't define source address spoofing defense, so what the -00 draft says is at best hopeful (but mostly just inaccurate). TLS does/can, so the idea of the PR is to let TLS do it. From nobody Wed Jan 11 17:51: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 35CAA129428 for ; Wed, 11 Jan 2017 17:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 43xgKtqqajI5 for ; Wed, 11 Jan 2017 17:51:21 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c: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 BE0EB1293F9 for ; Wed, 11 Jan 2017 17:51:20 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id x75so3731873vke.2 for ; Wed, 11 Jan 2017 17:51:20 -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=7d1B3B5AFwoXC25ElWiqNJrLcZENboAlIrGh5yzL3rw=; b=b+bT0tfDgc7aEfq37pYwppUAgYTyNpyxATEwaoj59lS/hr1o+DWehZkFP+o+wnkQty 09SLrNgKX/L1L74LQK4s3N/QNy5hYIyE/exWQdR+fHo59BRasX+hHTVAkDf7gTXqqNtS 1b7iIY1UeXdZjvVOcozJOyJIKUUCXVcC8lmjqrYkrF7bwYW1YROS+5yR0I4E1jh+M62h EG1lOnla7AP9GTj6n4/0Gkg9t3yh6FeUhCn+UHpysKr5SQxcQldEsud1JpeBlOnXQ1KC PEhOPzmgD2kpi4cXOoLJO2ufuJXLTb4K3Mwm4nHGn4cqmb3uEas413eaeCkil9i88p2U /f7Q== 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=7d1B3B5AFwoXC25ElWiqNJrLcZENboAlIrGh5yzL3rw=; b=E71eTh8dAyGukx4+R+EZNBXwPaBawOqb4RHPpKvt3YtodHNhSIuzAXpnW5OB3oKIoE u0VfPKlvneHEQ+tFPND/cknPBTsZmm6iS0MOg8wvjgnNvF9S+7VcH/YKw3x8ZVIwKtPz 4PCJEoi8B9xNKvF4M00QocYWiWDj0QAIFomPIXN7UqgVVk/BDx5qvw2xGaakeOYuMYuU ME8r70en2gde9GQtS074jSoOK+XBxJ0cDZHBq3aseKVq10bEBHwSbe5zxu/XSBNiLvQF BfSrl5LwmbRaPBBODT2JNJzxpF8iANkZB8y3WW6OdwapYqRooE+4DO7eWJyiRP2BZCFf PkMg== X-Gm-Message-State: AIkVDXLScwvTxlgI8EjYQgwuemk+efedB99C8x5n4gFzNUPwDfdaDIAGyngYEztjq3UQ5rY0AgWpgaW5qCIBN6vI X-Received: by 10.31.238.6 with SMTP id m6mr4951338vkh.28.1484185879760; Wed, 11 Jan 2017 17:51:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 17:51:19 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 17:51:19 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c1497142555730545dbf482 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:51:22 -0000 --94eb2c1497142555730545dbf482 Content-Type: text/plain; charset=UTF-8 I don't think QUIC needs to say anything about using TLS. The HTTP mapping draft should pull QUIC and TLS together so that any bits that go to port 443 have the bits delivered on stream 1 be TLS bits, but I don't think this is necessary for QUIC itself to require. On Wed, Jan 11, 2017 at 5:47 PM, Martin Thomson wrote: > On 12 January 2017 at 14:42, Jana Iyengar wrote: > > I'm not sure I follow the logic for combining QUIC and TLS versions as > well > > -- I expect that TLS version negotiation will happen on Stream 1 as per > its > > state machine. Why is this an issue? > > I think that the plan was to say that QUIC version 1 uses TLS (any > version). > --94eb2c1497142555730545dbf482 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think QUIC needs to say anything about using T= LS. The HTTP mapping draft should pull QUIC and TLS together so that any bi= ts that go to port 443 have the bits delivered on stream 1 be TLS bits, but= I don't think this is necessary for QUIC itself to require.=C2=A0

On Wed, Jan 11, = 2017 at 5:47 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 12 Janua= ry 2017 at 14:42, Jana Iyengar <jri@go= ogle.com> wrote:
> I'm not sure I follow the logic for combining QUIC and TLS version= s as well
> -- I expect that TLS version negotiation will happen on Stream 1 as pe= r its
> state machine. Why is this an issue?

I think that the plan was to say that QUIC version 1 uses TLS (any v= ersion).

--94eb2c1497142555730545dbf482-- From nobody Wed Jan 11 17:52: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 3385C129428 for ; Wed, 11 Jan 2017 17:52:30 -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 MTSkz653MkQG for ; Wed, 11 Jan 2017 17:52:29 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAA61293F9 for ; Wed, 11 Jan 2017 17:52:28 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id u25so6218833qki.2 for ; Wed, 11 Jan 2017 17:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2sA3RjPPPivaKKC1HaX5KGUlrH4r4h6hH9hUwgB4u/c=; b=k7KFRwyY2lQzU/cy1cNdVQWGlfMK1afbFT9Y/9EV36QpBrucSNRn+sRshQHr8bUs8F IR4Y4ne5Ly816Ior63ZkK7avyJpBPHz1gF6d7AQFrfkoXeYibwPGVmuTc+IUAIjfr6qO K9s1lYLXUQ2u+nTALLAF/iYn3mStHh9/QXnvOznob+voVS146tQFcQBE3M4rfH2KjR83 zLurFQW3RqhtM3fnqwHOEmIQcwP2Sd0VSnGR9Sib9/GB2gNzwzsjSqhdEZetRlvPQrPO AQmKrkBVjGiAU355ln+LtYBR2RdBBZDlFBjLFSsBnTpiLTM+8IkzMjoPCzXG+ALtMvzB iYPg== 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=2sA3RjPPPivaKKC1HaX5KGUlrH4r4h6hH9hUwgB4u/c=; b=Xfg9PjsTN9in7as2HUILttLXD37xWar9Y/U5QlInVLToEdZe6J5Hpb/3EziYWNHFnG 37lI3zzHSB/rYrjiJHDYuTyIZ2aLdKAC7XR6C9d2ti9YvZSDRQM1JrZIjxb3zhlCYokC T+fHLtkpc9+esRAO/yzWsQfx5Zdugr1JEqO8oJNJ27Pt6wSmdWdmvoHVoxIFZiKRjoaS ZWGZ7uIPyT0cSpEUAIKWhAf+sPsywvu5CVmjCHDZkzPUWNR9dBar5EGJhwoUG1prcTG1 ujdzBe7t9qh+7hLrZBbzbjWaWTHLceVsVJkIpvPn9yVxE/cJmRAUSezVHyTtYZmN9weU jE5Q== X-Gm-Message-State: AIkVDXLEY3rB6vIZmVrREvEqCcPB9ITs2nHS0m/urBKmAxsU3KZ7jEoHBYxHUqxLT1DW1tY7OLL0d4qXar/JOg== X-Received: by 10.55.164.85 with SMTP id n82mr8803495qke.316.1484185948209; Wed, 11 Jan 2017 17:52:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 11 Jan 2017 17:52:27 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 12 Jan 2017 14:52:27 +1300 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:52:30 -0000 On 12 January 2017 at 14:51, Jana Iyengar wrote: > I don't think QUIC needs to say anything about using TLS. The HTTP mapping > draft should pull QUIC and TLS together so that any bits that go to port 443 > have the bits delivered on stream 1 be TLS bits, but I don't think this is > necessary for QUIC itself to require. That means defining the QUIC version in an application mapping definition. Doesn't that go back to baking the QUIC version into the application protocol negotiation? From nobody Wed Jan 11 17:58: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 25509129458 for ; Wed, 11 Jan 2017 17:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 L-wY1SB71AZL for ; Wed, 11 Jan 2017 17:58:47 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44AB1293F9 for ; Wed, 11 Jan 2017 17:58:47 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id r136so3846353vke.1 for ; Wed, 11 Jan 2017 17:58: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=4cwlFt+92TDRMCUHo2OpVtoEtWcz0IYAVES37VnzNvc=; b=r5/qhIp8sEKMcUHQ47bN1+KB4QJDf9XEdhWWCTdR8qQ+Vb/FGbDF+76bmzRSNWqW4C gnGswPS3dvgsfD5Beh4I2QSByPvm9i/Ut94nfwKnAobN7Gpdz2t14lajy+soiwtMErtA H8OcS2tBNNdqwwBXHUK1b27MmbQotJuHmeWP0nauY2WBNeHJOSqT9V6zNvizbQI4AN3H MPQUOzYGMjTOCEkWLv17uPYyTiigK50UWSu+tHRBKTruPsYDRrhTyuwd3EK//UuGH33h BOgwNXrpeA+dkqQBuPR6NC4PndBup7FIlgwwXGb45sW54lIwQXJEV2aGsFeTqB66E9OG H/Ww== 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=4cwlFt+92TDRMCUHo2OpVtoEtWcz0IYAVES37VnzNvc=; b=CX57dhm2rycu233WRUiRrP2Hi+aHhWvQ3sM+9dNJvTOxihyc9KbeLmh2J4HI0ZsNSF /tjVQrKsuUsMZaDnV4zBkizoHcchFcd2rqMP+qdm8jfnABdfJepM1eSVFBwrIbeL4m7G mKIWi83ckO1AL8ayxsH12zggcN3amYaedoQHjvyiBaCgsc9tR4BwvoU8PcR1WDs3XjJG TrOCJwF9GkrLeADznt+ZoLM0Uth7gGDGzbydnvfqMhIijKjfqF+z3MwToSBpZwAF5iyZ Taaw3ECZptGjy0g4JQrlVcmzsSTOEEn/pOiCPE2s9pew92ZZE85SqkNx5lEq4e/WmFII OKGQ== X-Gm-Message-State: AIkVDXJP+Vdt9jDwqyAs7CB0fIb6L44q26VE0bpaW/v1WhpaHGNvVORvwcLLkXRH4yDaw+MVvO8ADrLQK4/lgOHs X-Received: by 10.31.92.1 with SMTP id q1mr4647106vkb.151.1484186326602; Wed, 11 Jan 2017 17:58:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 17:58:45 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 17:58:45 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e2b6ec778950545dc0e01 Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:58:49 -0000 --001a114e2b6ec778950545dc0e01 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2017 at 5:50 PM, Martin Thomson wrote: > On 12 January 2017 at 14:48, Jana Iyengar wrote: > > IIU 120 correctly, this moves the source-address token functionality into > > TLS. Why's this necessary? The current -00 draft says: > > " Source Address Spoofing Defense: Since QUIC handles source address > > verification, the crypto protocol SHOULD NOT impose a separate > > source address verification mechanism." > > > > This leaves the onus on the transport, which is similar to how TLS 1.3 > > interacts with TFO. > > Well, there we have a problem: QUIC doesn't define source address > spoofing defense, so what the -00 draft says is at best hopeful (but > mostly just inaccurate). TLS does/can, so the idea of the PR is to > let TLS do it. > Fair enough, and *I think* we should define source address spoofing defense in QUIC. Since the crypto handshake might provide it (if TLS is used with the right extension), maybe we could provide an out? (I'll need to read the TLS extension to ensure that it does all the things we may want to do, such as encode multiple source IP addresses within one token, to allow client IPs to change back and forth.) --001a114e2b6ec778950545dc0e01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 11, 2017 at 5:50 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 12 January 2017 at 14:48, Jana Iyengar <jri@google.com> wrote:
> IIU 120 correctly, this moves the source-address token functionality i= nto
> TLS. Why's this necessary? The current -00 draft says:
> " Source Address Spoofing Defense: Since QUIC handles source addr= ess
>=C2=A0 =C2=A0verification, the crypto protocol SHOULD NOT impose a sepa= rate
>=C2=A0 =C2=A0source address verification mechanism."
>
> This leaves the onus on the transport, which is similar to how TLS 1.3=
> interacts with TFO.

Well, there we have a problem: QUIC doesn't define source addres= s
spoofing defense, so what the -00 draft says is at best hopeful (but
mostly just inaccurate).=C2=A0 TLS does/can, so the idea of the PR is to let TLS do it.

Fair enough, and *I thin= k* we should define source address spoofing defense in QUIC. Since the cryp= to handshake might provide it (if TLS is used with the right extension), ma= ybe we could provide an out? (I'll need to read the TLS extension to en= sure that it does all the things we may want to do, such as encode multiple= source IP addresses within one token, to allow client IPs to change back a= nd forth.)

--001a114e2b6ec778950545dc0e01-- From nobody Wed Jan 11 18:03: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 97BB4129455 for ; Wed, 11 Jan 2017 18:03:56 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 Er1DEyMwVgbO for ; Wed, 11 Jan 2017 18:03:55 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4F4129458 for ; Wed, 11 Jan 2017 18:03:55 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id r144so685508wme.0 for ; Wed, 11 Jan 2017 18:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=es5KSeCovawsGN+2fn0uI+s90VEaRTzGk0vUeViLldk=; b=r8BFodQvcts0cLzbUra1DNAmfcb/Y71vdaiWYLjkNU8EyzLOaQE25L3v7F0jLpEJRd tX1wgTLjaWPKi+Nhwrq9pt4PzTomK8EuQmrkB00fC55SJRlSajyGTRQyomyRPssX21Pf mwe5Gx9BWjaNK/+RfIR9/uTx3OUah7XqhNNzX1Zol6FnEdVGq3QsGp9NLaT4G5sNosLB qxuA0Dt1hrBwE1TPPM/e92NIZCp6RqKm2clDq2TWuJqTOrsam8neN/QpmbMPcBJzQoPm GreQcQQiGCZDhKJwgOx0mJ0jpel2n9EeRtgFVSUsXmE0eZeAlyZN7ruP8g6OTfvYG0UQ wDJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=es5KSeCovawsGN+2fn0uI+s90VEaRTzGk0vUeViLldk=; b=S+rJMl1Vt1dZ3eZmiI8WWJFlsSyzpRahY+d3b6aR/UG+3C2v2NOAScx6mIW6Uhln7Y O4N1zHyG1umgKWueiF6SqxyqX6VbQFLUcz5SHxNbQnO1FUTFuwO5/4hTGwPAY8FL9IJv dusakDNmZkLxaPI1qWSoxDTSE3wIj4ZTHJwAIicG21iGdeqFvfpwOMLr3sucuR3vuOA4 plZvxHHqYzqIt+3dS8VLL07O5A2TimXhCnH6H65w46Wz5KFQieNVsn+3OPrKJfB8WHUK XX+JnaBo/aP8efaQDJkK3WSmKGl79t88LxrXStcFAiRehfyHOs+/vMBjPIbz8DXYeny6 Gb8w== X-Gm-Message-State: AIkVDXLbWw5FbzVqLZytt+mfzm6EVGFmyYlgsxZmDxd39Lw5a8QqzKT3f2bHMjuF6ZBunpekVR88+2Cs2wgGzQ== X-Received: by 10.28.226.67 with SMTP id z64mr4614761wmg.137.1484186633528; Wed, 11 Jan 2017 18:03:53 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Wed, 11 Jan 2017 18:03:52 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 11 Jan 2017 21:03:52 -0500 X-Google-Sender-Auth: VZlICiH2oJd-5-H3w1UZRRxxuEs Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114b0d08126ced0545dc2134 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:03:56 -0000 --001a114b0d08126ced0545dc2134 Content-Type: text/plain; charset=UTF-8 Before folk go too far down the TLS rabbit hole. Consider that the Web isn't just about browsing, it is also about Web Services and TLS isn't necessarily a suitable security solution for a Web Service. In process control (i.e. SCADA) security, the concern is authenticity, not confidentiality. If you talk to process control folk they will often say that they don't want their packets to have encryption. They want authentication, not confidentiality. They also tend to run their networks in a very different style. They don't usually tolerate chatty protocols that broadcast noise for no particular reason. For this type of application, QUIC offers a lot of benefits but they are probably going to want to do authentication at the transaction level rather than transport. --001a114b0d08126ced0545dc2134 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bef= ore folk go too far down the TLS rabbit hole. Consider that the Web isn'= ;t just about browsing, it is also about Web Services and TLS isn't nec= essarily a suitable security solution for a Web Service.

In process control (i.e. SCADA) security, t= he concern is authenticity, not confidentiality. If you talk to process con= trol folk they will often say that they don't want their packets to hav= e encryption. They want authentication, not confidentiality. They also tend= to run their networks in a very different style. They don't usually to= lerate chatty protocols that broadcast noise for no particular reason.

For this type of application,= QUIC offers a lot of benefits but they are probably going to want to do au= thentication at the transaction level rather than transport.
--001a114b0d08126ced0545dc2134-- From nobody Wed Jan 11 18:21: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 6F2471293EB for ; Wed, 11 Jan 2017 18:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, 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 9IUlebem9pfV for ; Wed, 11 Jan 2017 18:21:18 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0510E126BF7 for ; Wed, 11 Jan 2017 18:21:17 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 35so4700096uak.1 for ; Wed, 11 Jan 2017 18:21:17 -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=4x4/VMW9a4OjZkJHBQyFTlr5Uh8XlBfLaeX6CWkGaVk=; b=FLYtm7DFSSUkCTaxykMAximvKbsL8AbXDRHLR+odEMEZFU2wa0dcfvANJCLOa5pWkB VU53DbMvMo5JhyKgl2LeDfveLyjyvOk9PcftAiSBRHiftoDo2uuaITETadeqSlB4ODUt SBYUSLruRYo8iVL37EcM1SBj7H2p8iY0KMhIqx/eMBAETG/5Q5FQaHxwoM55QWcLIRni 39O/mVrlKckIfW4eCQewVPTzWyxW5DmsOpH4r7fhYnnI+ksjlfh/MoS9/FRyyV/C6J3h jcQJnOH65Jc53ylLBhOTHemoGz7uKsioc+W2hKGIf7Seuu6HFAuaWkt/qQ9Mo4AgRO90 uy7w== 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=4x4/VMW9a4OjZkJHBQyFTlr5Uh8XlBfLaeX6CWkGaVk=; b=tm6UQ/GSzLPn8nqqZ6p9Bk6sZEs8Pe+mWh6H3u2MhfmHxukUuJZcZZuyWBalv1y7Rk 90QkB9rag4J2ToIJjZChrpdKbsvZeryaZllLJRHVv0gWYviHAHncOHl1qXu78n6saMQn jMPFNMwpym+Qn89o7prCMaLOMZ05CGzEVRvAiNNr51H2CCoj9z/XGfhVNcldLourLk0c PXLoL1Ao6AAyo0hg4cG4lqDw348BuOaOYLvCGC6mMj7J5tRlaNfVDY2UZnm6fy14RO7T 5183IqWw1ABm4doDNTj9N2IQbInJyxdYzm1N4r+YbvAaZF9GXmL7bnITfaVhF8o/TL/t CTfg== X-Gm-Message-State: AIkVDXLVKcjYhLPG8F0XcMIiROOZsMSn2ULVRoNnx52uv+5uLMBsyNPT7NRcR1v6FAKLYn6P91d03AgLpnnqcT5T X-Received: by 10.176.84.211 with SMTP id q19mr4094730uaa.136.1484187676843; Wed, 11 Jan 2017 18:21:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 18:21:16 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 18:21:16 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c1b10e44260c60545dc5f1f Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:21:19 -0000 --94eb2c1b10e44260c60545dc5f1f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2017 at 5:52 PM, Martin Thomson wrote: > On 12 January 2017 at 14:51, Jana Iyengar wrote: > > I don't think QUIC needs to say anything about using TLS. The HTTP > mapping > > draft should pull QUIC and TLS together so that any bits that go to port > 443 > > have the bits delivered on stream 1 be TLS bits, but I don't think this > is > > necessary for QUIC itself to require. > > > That means defining the QUIC version in an application mapping > definition. Doesn't that go back to baking the QUIC version into the > application protocol negotiation? > I think so, but what do you mean by "going back to"? Did I say something else at some point? I'm entirely capable :-) I did say that the HTTP mapping pulls QUIC and TLS together, so I think that would need the HTTP mapping to know the QUIC version, which seems reasonable to me. For clarity, as I imagine it: - an HTTP/x client initiates a QUICvN with TLS1.K. This first creates a QUIC packet that contains a TLS ClientHello message (which has ALPN set to "hXq"). - QUIC version negotiation is isolated from anything that happens on Stream 1. Specifically, QUIC will retransmit the TLS ClientHello bits as per QUIC version negotiation. - From TLS's point of view, the encapsulating QUIC packet is irrelevant. Its view is that of the TLS version, and ALPN for negotiating the right application atop. The ALPN is tied to the version of HTTP mapping which is tied to a version of both the transport and TLS mapping drafts. --94eb2c1b10e44260c60545dc5f1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 11, 2017 at 5:52 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 12 January 2017 at 14:51, Jana Iyengar <<= a href=3D"mailto:jri@google.com">jri@google.com> wrote:
> I don't think QUIC needs to say anything about using TLS. The HTTP= mapping
> draft should pull QUIC and TLS together so that any bits that go to po= rt 443
> have the bits delivered on stream 1 be TLS bits, but I don't think= this is
> necessary for QUIC itself to require.


That means defining the QUIC version in an application mapping
definition.=C2=A0 Doesn't that go back to baking the QUIC version into = the
application protocol negotiation?

I think so, but wha= t do you mean by "going back to"? Did I say something else at som= e point? I'm entirely capable :-)=C2=A0

I did say that the HTTP mapping pulls= QUIC and TLS together, so I think that would need the HTTP mapping to know= the QUIC version, which seems reasonable to me. For clarity, as I imagine = it:
- an HTTP/x client initiates a QUICvN w= ith TLS1.K. This first creates a QUIC packet that contains a TLS ClientHell= o message (which has ALPN set to "hXq").
- QUIC version negotiation is isolated from anything that happens o= n Stream 1. Specifically, QUIC will retransmit the TLS ClientHello bits as = per QUIC version negotiation.
- From TLS= 9;s point of view, the encapsulating QUIC packet is irrelevant. Its view is= that of the TLS version, and ALPN for negotiating the right application at= op. The ALPN is tied to the version of HTTP mapping which is tied to a vers= ion of both the transport and TLS mapping drafts.


--94eb2c1b10e44260c60545dc5f1f-- From nobody Wed Jan 11 18:26: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 2F05B12943A for ; Wed, 11 Jan 2017 18:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 sAXw1108HEEc for ; Wed, 11 Jan 2017 18:26:39 -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 A3FAA129441 for ; Wed, 11 Jan 2017 18:26:39 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id t8so4079661vke.3 for ; Wed, 11 Jan 2017 18:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZPqZGb17Pghv7yZ4kOHx2UG+s0mJk5wBlodE6KWFUbo=; b=VzKVVfWAW4KrBCc76/JiA7vC/rIW9x6Tte0dMjf7KnF1ZAm9FUjAHRKVs1Sv25Oq6p 4l+70e4aBFkhRw/8YzoXhup+X6vgvrctUHSWqaKbYRlJXlS1uAkrC5F2THQJv1jUvfOK JiyIEHeE+biFXZvPemFySE6LGZ4oFIuWYX+ePAl91kzu5W/nH6uWjRq8IROVIDrtEO8a AbAw6wxzZrof0I8XXgIxbTkg+h6VBF6BLgJw68O6uIBqhO7iaqWbbs7m3diLAlqiJHl5 YwMmwj/FO8B4WTcgFA9Ge6lxOZPcLboZ8bVin0luU2rRlPcTIkaL8pZ+UtThp+5i+zl8 7VMw== 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=ZPqZGb17Pghv7yZ4kOHx2UG+s0mJk5wBlodE6KWFUbo=; b=o6OP8qZ/aEPKTscDcc1i/UTBw4u6Fs6w2eUjoL9Qs+eVtzeu6buomAL6fQtgYnrsxc sLdRw/PrJS3frH6y/xoVdpiIa+Ou2caaI46myhZfEkhd/F4A4pn3/KzoDNVdT4vagqSp 93XaLw69mF+VwRh1a7+AcdsIaXuA6CNCESTlNiuzOVavSUxJrURk2Myxkru3zCjhY/GH y5p3OzT/II+1duLuXTIxQVdgdLTAWWz8O4lV95jLb3SQGeHJOOuYvQPmBXTZ1L0/dm5p tqh+vTTKHWTfLOJ1Dc6+TfJgsWqSvVZFpo3f2L/D/rrbiF/djTI4fVrTXKbZa1E/3sNl mAEQ== X-Gm-Message-State: AIkVDXL2z0fdgs4PRkRParo3+mox/jxdbdyhqBd5Sr6uHh+uH95rdRR+39XJZwEbs+s0p/sMWCRqOtU/E20eEqPl X-Received: by 10.31.238.6 with SMTP id m6mr4997320vkh.28.1484187998575; Wed, 11 Jan 2017 18:26:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 18:26:37 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 18:26:37 -0800 Message-ID: Subject: Re: Using different crypto To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c1497146fd5b50545dc72cd Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:26:41 -0000 --94eb2c1497146fd5b50545dc72cd Content-Type: text/plain; charset=UTF-8 > In process control (i.e. SCADA) security, the concern is authenticity, not > confidentiality. If you talk to process control folk they will often say > that they don't want their packets to have encryption. They want > authentication, not confidentiality. > Unencrypted transport is not in scope for the wg. From https://datatracker.ietf.org/wg/quic/charter/: "The QUIC working group will provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol ..." Unencrypted transport unfortunately leads to an ossified transport. --94eb2c1497146fd5b50545dc72cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
In process control (i.e. SCADA) security, the concer= n is authenticity, not confidentiality. If you talk to process control folk= they will often say that they don't want their packets to have encrypt= ion. They want authentication, not confidentiality.

Unencrypted transpo= rt is not in scope for the wg. From=C2=A0https://datatracker.ietf.org/wg/quic/charter/:= =C2=A0"The QUIC working group will provide a standards-track specifica= tion for a UDP-based, stream-multiplexing, encrypted transport protocol ...= "

Unencrypted transport unfortunately leads to an ossified transport.
<= div class=3D"gmail_extra">
--94eb2c1497146fd5b50545dc72cd-- From nobody Wed Jan 11 18:27: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 3415F129461 for ; Wed, 11 Jan 2017 18:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 NxL8BCEr_hUp for ; Wed, 11 Jan 2017 18:26:59 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0120.outbound.protection.outlook.com [104.47.42.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5BB12943A for ; Wed, 11 Jan 2017 18:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8sAWYjFOMErfngcznJJnD2Rrr7f2TbBRwmRFbyIoL08=; b=T3HMjrDG9t6d0BucWWktAebMB4d+I14xVCvyRZ+tBs/3OdF24bNgTaq2ng8dDqUPaZ+3gBpm9sn+ER9DAz0caLs/YnTsSMKRP7mNBp/qYzKVrvslqeiABmuWlf/bc88cB4CZ5mmoTCloE79qzPWEN735Xxgj/2WevBQ4QPijTCQ= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 02:26:57 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 02:26:57 +0000 From: Mike Bishop To: Jana Iyengar , Martin Thomson Subject: RE: Using different crypto Thread-Topic: Using different crypto Thread-Index: AdJqwmguSJ5RH5YtRcG/iV7NxHADeQBeJWuAAAC914AAAI/MAAAAqlKAAAYr4GAAAK2xgAAA4/2AAATPSAAAADUNAAAAHkCAAAAKIoAAAQGkAAAAMt+s Date: Thu, 12 Jan 2017 02:26:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:600:8300:3b9a:2175:b98d:e538:f911] x-ms-office365-filtering-correlation-id: a7f68083-dde6-426f-2cf4-08d43a927b75 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:p/VZQAV5qQdgwP8wJOqnTE+n3NbrEb140B+i1hHLbuwRALyo2xZvtkdovL61OqdX8TUDVeTJqJjgS5DqKkrNiM7H1usn8kQZSv4RvEm3P2RZ34xGaWjUuHUrPy9GeiNa8/ldFBaVHj+2H4d6YqK57P5s09v8VQUgi1nQKWY1GeK3sOnZmnDucxs7J3V3j8WKSrmrlb6CbnZKXKu6PpLqjeRiihUz9VW7696K2hrdEhCw2MHqV26exfkbqeEUeby1QZCihJhwGJ3XCiBPWaxDm85MiGSm7lv7fThSIMa1E6DI+6rZSLk0YklMd7b99U8fFgIODaqHF0d3wOdWAmDhzRemrmUtvpEl2miIq3Y2nkysT5l18e6oFjDaSJl+EDIf3wTjrp+v5hY+HD60tnI64rs2QerTZj7ffOO3iTYQ7/PHUfFNgkr05Qeks5mU7GINpRk6Hv7yg3w2H0FyfuXYJAzVIuYn83wdApPfPGTHtgM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(199003)(189002)(377454003)(24454002)(51444003)(93886004)(5005710100001)(8676002)(7736002)(54906002)(74316002)(8990500004)(81156014)(99286003)(8936002)(81166006)(229853002)(3660700001)(77096006)(6506006)(6436002)(55016002)(39060400001)(38730400001)(189998001)(3900700001)(5001770100001)(97736004)(25786008)(122556002)(92566002)(7116003)(54356999)(33656002)(2950100002)(76176999)(50986999)(102836003)(105586002)(6116002)(5660300001)(2900100001)(10090500001)(54896002)(10290500002)(7696004)(106356001)(101416001)(68736007)(3480700004)(236005)(86612001)(9686003)(2906002)(4326007)(3280700002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708D89B362F73BB2B492D5987790BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 02:26:57.5354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Cc: "Salz, Rich" , Ted Hardie , IETF QUIC WG , Patrick McManus , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:27:01 -0000 --_000_BN6PR03MB2708D89B362F73BB2B492D5987790BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At one point, ALPN tokens implied an app protocol + QUIC version + crypto p= rotocol 3-tuple. We changed this in one of the PRs (already merged?), we c= hanged this because you can't *find* the ALPN token until you've already ag= reed on version and handshake protocol. Now it says that ALPN specifies th= e app protocol ONLY, and the app protocol MAY restrict which versions of QU= IC it can be used with. In the big PR on HTTP, BTW, the TLS restriction has been removed. If peopl= e want it back, we certainly can, but I don't see a hard requirement. Sent from my Windows 10 phone From: Jana Iyengar Sent: Wednesday, January 11, 2017 6:21 PM To: Martin Thomson Cc: Ted Hardie; Mike Bishop; Martin Duke; Patrick McMa= nus; Salz, Rich; IETF= QUIC WG Subject: Re: Using different crypto On Wed, Jan 11, 2017 at 5:52 PM, Martin Thomson > wrote: On 12 January 2017 at 14:51, Jana Iyengar > wrote: > I don't think QUIC needs to say anything about using TLS. The HTTP mappin= g > draft should pull QUIC and TLS together so that any bits that go to port = 443 > have the bits delivered on stream 1 be TLS bits, but I don't think this i= s > necessary for QUIC itself to require. That means defining the QUIC version in an application mapping definition. Doesn't that go back to baking the QUIC version into the application protocol negotiation? I think so, but what do you mean by "going back to"? Did I say something el= se at some point? I'm entirely capable :-) I did say that the HTTP mapping pulls QUIC and TLS together, so I think tha= t would need the HTTP mapping to know the QUIC version, which seems reasona= ble to me. For clarity, as I imagine it: - an HTTP/x client initiates a QUICvN with TLS1.K. This first creates a QUI= C packet that contains a TLS ClientHello message (which has ALPN set to "hX= q"). - QUIC version negotiation is isolated from anything that happens on Stream= 1. Specifically, QUIC will retransmit the TLS ClientHello bits as per QUIC= version negotiation. - From TLS's point of view, the encapsulating QUIC packet is irrelevant. It= s view is that of the TLS version, and ALPN for negotiating the right appli= cation atop. The ALPN is tied to the version of HTTP mapping which is tied = to a version of both the transport and TLS mapping drafts. --_000_BN6PR03MB2708D89B362F73BB2B492D5987790BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At one point, ALPN tokens implied an app protocol &#= 43; QUIC version + crypto protocol 3-tuple.  We changed this in on= e of the PRs (already merged?), we changed this because you can't *find<= /b>* the ALPN token until you've already agreed on version and handshake protocol.  Now it says that ALPN specifies t= he app protocol ONLY, and the app protocol MAY restrict which versions of Q= UIC it can be used with.

 

In the big PR on HTTP, BTW, the TLS restriction has = been removed.  If people want it back, we certainly can, but I don't s= ee a hard requirement.

 

Sent from my Windows 10 phone

 

From: Jana Iyengar
Sent: Wednesday, January 11, 2017 6:21 PM
To: Martin Thomson Cc: Ted Hardie; Mike Bishop; Martin Duke= ; Patrick McManus; Salz, Rich; IETF QUIC WG
Subject: Re: Using different crypto

 

On Wed, Jan 11, 2017 at 5:52 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 12 January 2017 at 14:51, Jana Iyengar <jri@google.com> wrote:
> I don't think QUIC needs to say anything about using TLS. The HTTP map= ping
> draft should pull QUIC and TLS together so that any bits that go to po= rt 443
> have the bits delivered on stream 1 be TLS bits, but I don't think thi= s is
> necessary for QUIC itself to require.


That means defining the QUIC version in an application mapping
definition.  Doesn't that go back to baking the QUIC version into the<= br> application protocol negotiation?

I think so, but what do you mean by "going = back to"? Did I say something else at some point? I'm entirely capable= :-) 

I did say that the HTTP mapping pulls QUIC and T= LS together, so I think that would need the HTTP mapping to know the QUIC v= ersion, which seems reasonable to me. For clarity, as I imagine it:
- an HTTP/x client initiates a QUICvN with TLS1.= K. This first creates a QUIC packet that contains a TLS ClientHello message= (which has ALPN set to "hXq").
- QUIC version negotiation is isolated from anyt= hing that happens on Stream 1. Specifically, QUIC will retransmit the TLS C= lientHello bits as per QUIC version negotiation.
- From TLS's point of view, the encapsulating QU= IC packet is irrelevant. Its view is that of the TLS version, and ALPN for = negotiating the right application atop. The ALPN is tied to the version of = HTTP mapping which is tied to a version of both the transport and TLS mapping drafts.


--_000_BN6PR03MB2708D89B362F73BB2B492D5987790BN6PR03MB2708namp_-- From nobody Wed Jan 11 18:43: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 0FB56129406 for ; Wed, 11 Jan 2017 18:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 qZmbCrecLVqJ for ; Wed, 11 Jan 2017 18:43:22 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69FFE126BF7 for ; Wed, 11 Jan 2017 18:43:22 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id y9so4939473uae.2 for ; Wed, 11 Jan 2017 18:43:22 -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=p8hORlLJkuGU9UvAkFbY+4lSBkqjpSeM1j688PCBuCk=; b=aCZ5ut8KWNKGoplMWkOFuwzdfqMDpqnYjEYpZs7GTt5tJce8/vIM/8ERfa+hqqrXo6 AwXLPJZAV0HJn7MPCMR9B4SQHJ/1qN/XY2xOplTE8gWfIskHxc2tQ6FWYaIyjwcykFfI MPAuf5Xgyv3WJ6q4yQKnDmyG07AWllvRG7KdQRi1qtM/kwRLFAqsVmUPri7WCofe1pOM MrGc5uJb7hrBo0Qkrh7xMDWu8o2oTltSgLlPJAHeLpEGTr2LldSTK6KmJIJhn6lHE6mj CCGHpU6ZajUY0F6QRg5br0CsROuBs30200VTts0JXyS8MBzGM/jTMoe22IzGlLTEMjaq 5/wQ== 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=p8hORlLJkuGU9UvAkFbY+4lSBkqjpSeM1j688PCBuCk=; b=d4OP91NlwiljTlBUg7U2oJV84KNMkMQdyFYez73y4/cm8ZQO5b5W1FnwSg81I6LcR4 rfGj3ZU1f+8duTzGPOehrXx5Ns/NRtwrYbDoktAgiJemNLMrishkL4496f2AwAYybC1E AvGk/E9dshm5yobLSbp19oqOVQO04wZKYL1BrJhi6eMdfI+nX54pS+jd7VG5UPDpL7qy ihAKtuscjmJGKVAouAI2D8iIgt5ggJQz6VcruaIP/uSxEu2JU5ED1FKTG+leuq5s4bXZ uoDVGTTfVMJ1qEAFZJEf07smqvBM0eZ0EOGJMImdN68k7LHI2qo2vasYYogF1Hxf78Be llVQ== X-Gm-Message-State: AIkVDXIu+Lf8kNzS4HHR/0/CHrP9S58lrWqIhSsX31e9V6BSVUCl58jNGBLnUikBgyk/fMwOdXHc6o/dwyj+9C02 X-Received: by 10.159.49.92 with SMTP id n28mr5573800uab.95.1484189001352; Wed, 11 Jan 2017 18:43:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 18:43:20 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 18:43:20 -0800 Message-ID: Subject: Re: Using different crypto To: Mike Bishop Content-Type: multipart/alternative; boundary=f403045dd9d834c49a0545dcaedf Archived-At: Cc: Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:43:24 -0000 --f403045dd9d834c49a0545dcaedf Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2017 at 6:26 PM, Mike Bishop wrote: > At one point, ALPN tokens implied an app protocol + QUIC version + crypto > protocol 3-tuple. We changed this in one of the PRs (already merged?), we > changed this because you can't **find** the ALPN token until you've > already agreed on version and handshake protocol. Now it says that ALPN > specifies the app protocol ONLY, and the app protocol MAY restrict which > versions of QUIC it can be used with. > I missed it. I'll go take a look, but this definitely sounds like something that needs to be discussed, perhaps at the interim. But I don't follow the problem -- it seems obvious that you can't find the ALPN token until the TLS version is agreed upon. So, in my imaginary world, the ALPN token indicates the version of the HTTP mapping document, which specifies the QUIC and TLS versions. *I think* it's reasonable to expect that the HTTP layer confirms the current TLS version being used meets the requirements of the one specified through the ALPN tag, and the QUIC version in use meets the requirements of the ALPN tag. In the big PR on HTTP, BTW, the TLS restriction has been removed. If > people want it back, we certainly can, but I don't see a hard requirement. > I don't understand what it means to remove the TLS restriction. It seems odd to have HTTP running on top of an encrypted transport but not have a TLS requirement. Is the idea that we could use something other than TLS for HTTPS? - jana > > > Sent from my Windows 10 phone > > > > *From: *Jana Iyengar > *Sent: *Wednesday, January 11, 2017 6:21 PM > *To: *Martin Thomson > *Cc: *Ted Hardie ; Mike Bishop > ; Martin Duke ; Patrick > McManus ; Salz, Rich ; IETF QUIC > WG > *Subject: *Re: Using different crypto > > > On Wed, Jan 11, 2017 at 5:52 PM, Martin Thomson > wrote: > > On 12 January 2017 at 14:51, Jana Iyengar wrote: >> > I don't think QUIC needs to say anything about using TLS. The HTTP >> mapping >> > draft should pull QUIC and TLS together so that any bits that go to >> port 443 >> > have the bits delivered on stream 1 be TLS bits, but I don't think this >> is >> > necessary for QUIC itself to require. >> >> >> That means defining the QUIC version in an application mapping >> definition. Doesn't that go back to baking the QUIC version into the >> application protocol negotiation? >> > > I think so, but what do you mean by "going back to"? Did I say something > else at some point? I'm entirely capable :-) > > I did say that the HTTP mapping pulls QUIC and TLS together, so I think > that would need the HTTP mapping to know the QUIC version, which seems > reasonable to me. For clarity, as I imagine it: > - an HTTP/x client initiates a QUICvN with TLS1.K. This first creates a > QUIC packet that contains a TLS ClientHello message (which has ALPN set to > "hXq"). > - QUIC version negotiation is isolated from anything that happens on > Stream 1. Specifically, QUIC will retransmit the TLS ClientHello bits as > per QUIC version negotiation. > - From TLS's point of view, the encapsulating QUIC packet is irrelevant. > Its view is that of the TLS version, and ALPN for negotiating the right > application atop. The ALPN is tied to the version of HTTP mapping which is > tied to a version of both the transport and TLS mapping drafts. > > > --f403045dd9d834c49a0545dcaedf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 11, 2017 at 6:26 PM, Mike Bishop <Michael.Bishop@micros= oft.com> wrote:

At one point, ALPN tokens implied an app protocol + = QUIC version + crypto protocol 3-tuple.=C2=A0 We changed this in one of the= PRs (already merged?), we changed this because you can't *find*= the ALPN token until you've already agreed on version and handshake protocol.=C2=A0 Now it says that ALPN specifies t= he app protocol ONLY, and the app protocol MAY restrict which versions of Q= UIC it can be used with.


I = missed it. I'll go take a look, but this definitely sounds like somethi= ng that needs to be discussed, perhaps at the interim. But I don't foll= ow the problem -- it seems obvious that you can't find the ALPN token u= ntil the TLS version is agreed upon. So, in my imaginary world, the ALPN to= ken indicates the version of the HTTP mapping document, which specifies the= QUIC and TLS versions.=C2=A0

*I think* it's r= easonable to expect that the HTTP layer confirms the current TLS version be= ing used meets the requirements of the one specified through the ALPN tag, = and the QUIC version in use meets the requirements of the ALPN tag.

<= /u>

In the big PR on HTTP, BTW, the TLS restriction has = been removed.=C2=A0 If people want it back, we certainly can, but I don'= ;t see a hard requirement.


= I don't understand what it means to remove the TLS restriction. It seem= s odd to have HTTP running on top of an encrypted transport but not have a = TLS requirement. Is the idea that we could use something other than TLS for= HTTPS?

- jana
=C2=A0

=C2=A0

Sent from my Windows 10 phone

=C2=A0

From: Jana Iyengar
Sent: Wednesday, January 11, 2017 6:21 PM
To: Ma= rtin Thomson
Cc: Ted Hard= ie; Mike Bishop; Martin Duke; Patrick McManus; = Salz, Rich; IETF QUIC WG
Subject: Re: Using different crypto

=C2=A0

On Wed, Jan 11, 2017 at 5:52 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:

On 12 January 2017 at 14:= 51, Jana Iyengar <jr= i@google.com> wrote:
> I don't think QUIC needs to say anything about using TLS. The HTTP= mapping
> draft should pull QUIC and TLS together so that any bits that go to po= rt 443
> have the bits delivered on stream 1 be TLS bits, but I don't think= this is
> necessary for QUIC itself to require.


That means defining the QUIC version in an application mapping
definition.=C2=A0 Doesn't that go back to baking the QUIC version into = the
application protocol negotiation?

I think so, but what do you mean by "going = back to"? Did I say something else at some point? I'm entirely cap= able :-)=C2=A0

I did say that the HTTP mapping pulls QUIC and T= LS together, so I think that would need the HTTP mapping to know the QUIC v= ersion, which seems reasonable to me. For clarity, as I imagine it:
- an HTTP/x client initiates a QUICvN with TLS1.= K. This first creates a QUIC packet that contains a TLS ClientHello message= (which has ALPN set to "hXq").
- QUIC version negotiation is isolated from anyt= hing that happens on Stream 1. Specifically, QUIC will retransmit the TLS C= lientHello bits as per QUIC version negotiation.
- From TLS's point of view, the encapsulatin= g QUIC packet is irrelevant. Its view is that of the TLS version, and ALPN = for negotiating the right application atop. The ALPN is tied to the version= of HTTP mapping which is tied to a version of both the transport and TLS mapping drafts.



--f403045dd9d834c49a0545dcaedf-- From nobody Wed Jan 11 18:46: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 ECBF9129412 for ; Wed, 11 Jan 2017 18:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncp_UqzEgXQc for ; Wed, 11 Jan 2017 18:46:35 -0800 (PST) Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0A11293E9 for ; Wed, 11 Jan 2017 18:46:35 -0800 (PST) Received: by mail-wj0-x242.google.com with SMTP id dh1so498707wjb.3 for ; Wed, 11 Jan 2017 18:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CyaL8NDWPepuH8ITwiVKxYo8rrGo4H0wH6vDq3mvOt0=; b=HNrb9dOjM+uhTwXF3ysNi+g06g6sfY4FavCBFCwtx6xOmBkbjIPSXweq8rxJZ/z7lQ NNLyoCqdgtwA5vlz/nMRW1gpg9AwvAPPnn4FlOc5cOCJFXnuxDRi844wvDI1zXwADyn0 NWWOeNY3uus9syPultW6KTS5Xs0H30+Dk+1srDQEHeCluUTVtYpvolULbidXbWFuIt5h ny8/2Rmrs4ZICsw1YIK7JzgR2QLCg3xRnglq4z2fyS5CTfgnKJVSwbnOwOSX+2P5xXnO Sh5Z8RNH8peAIj/7dKkarDE5vidv0EV/O553QxpaGVsjj9/Dn3pqZ/tLLkGSgRTvjjQH oUuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CyaL8NDWPepuH8ITwiVKxYo8rrGo4H0wH6vDq3mvOt0=; b=co23X8lh7Z//EHmGuPlDfjReVW7qJ2Vryh9izQcsUdtHj2IUNI5677tjnXNl9blHRq E73UZoMJDQWaXA9qHAcokZOvRWkiwtWl5p531xzpA7OiKbK0oor2k+KGBCdh47wTJ/j/ elW/V82xXdQC6GsoJ1DpUgZlRjHgm2Y4J9NCB49olNilIxWVODeDqSAIfAKNk8Sd++6o QEMCshDmht2Rn0qT0/L/oiblJofmTEOV78OW1SJUJkAWlIrGUD9BoF57XkQj/+DM5Yfr 1L4xqVgRRfNWmqyYNk7mvmkXktKi2dOnGfJifbgJQ9zyNA9SBdyIaBF5FMLqLNRRc2Kq okRA== X-Gm-Message-State: AIkVDXL9wNJF52NZHbkjyeJkB215GcORuBw+mmU2hGzgmFWB6WRyB2BxCeKQbMjLhaOsSSiuKTqnYVzPb0Ujuw== X-Received: by 10.194.137.70 with SMTP id qg6mr1427101wjb.6.1484189193643; Wed, 11 Jan 2017 18:46:33 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Wed, 11 Jan 2017 18:46:32 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 11 Jan 2017 21:46:32 -0500 X-Google-Sender-Auth: 3nKmBnNEJ5_oM8Io5LcvTMquix8 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar Content-Type: multipart/alternative; boundary=bcaec50fe41faaaeb90545dcb990 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:46:37 -0000 --bcaec50fe41faaaeb90545dcb990 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2017 at 9:43 PM, Jana Iyengar wrote: > On Wed, Jan 11, 2017 at 6:26 PM, Mike Bishop > wrote: > >> At one point, ALPN tokens implied an app protocol + QUIC version + crypt= o >> protocol 3-tuple. We changed this in one of the PRs (already merged?), = we >> changed this because you can't **find** the ALPN token until you've >> already agreed on version and handshake protocol. Now it says that ALPN >> specifies the app protocol ONLY, and the app protocol MAY restrict which >> versions of QUIC it can be used with. >> > > I missed it. I'll go take a look, but this definitely sounds like > something that needs to be discussed, perhaps at the interim. But I don't > follow the problem -- it seems obvious that you can't find the ALPN token > until the TLS version is agreed upon. So, in my imaginary world, the ALPN > token indicates the version of the HTTP mapping document, which specifies > the QUIC and TLS versions. > > *I think* it's reasonable to expect that the HTTP layer confirms the > current TLS version being used meets the requirements of the one specifie= d > through the ALPN tag, and the QUIC version in use meets the requirements = of > the ALPN tag. > > In the big PR on HTTP, BTW, the TLS restriction has been removed. If >> people want it back, we certainly can, but I don't see a hard requiremen= t. >> > > I don't understand what it means to remove the TLS restriction. It seems > odd to have HTTP running on top of an encrypted transport but not have a > TLS requirement. Is the idea that we could use something other than TLS f= or > HTTPS? > =E2=80=8BYes. TLS is built with TCP in mind using 1990s crypto. It has been extended multiple times. At some point you either profile or start from scratch. =E2= =80=8B --bcaec50fe41faaaeb90545dcb990 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Ja= n 11, 2017 at 9:43 PM, Jana Iyengar <jri@google.com> wrote:
=
=
On Wed, Jan 11, 2017 at 6:26 PM= , Mike Bishop <Michael.Bishop@microsoft.com> wrot= e:

At one point, ALPN tokens implied an app protocol + = QUIC version + crypto protocol 3-tuple.=C2=A0 We changed this in one of the= PRs (already merged?), we changed this because you can't *find*= the ALPN token until you've already agreed on version and handshake protocol.=C2=A0 Now it says that ALPN specifies t= he app protocol ONLY, and the app protocol MAY restrict which versions of Q= UIC it can be used with.


=
I missed it. I'll go take a look, but this definitely sounds like = something that needs to be discussed, perhaps at the interim. But I don'= ;t follow the problem -- it seems obvious that you can't find the ALPN = token until the TLS version is agreed upon. So, in my imaginary world, the = ALPN token indicates the version of the HTTP mapping document, which specif= ies the QUIC and TLS versions.=C2=A0

*I think* it&= #39;s reasonable to expect that the HTTP layer confirms the current TLS ver= sion being used meets the requirements of the one specified through the ALP= N tag, and the QUIC version in use meets the requirements of the ALPN tag.<= /div>

In the big PR on HTTP, BTW, the TLS restriction has = been removed.=C2=A0 If people want it back, we certainly can, but I don'= ;t see a hard requirement.


I don't understand what it means to remove the TLS restriction. = It seems odd to have HTTP running on top of an encrypted transport but not = have a TLS requirement. Is the idea that we could use something other than = TLS for HTTPS?

=E2=80=8BYes.

TLS is built with TCP in mind using 1990= s crypto. It has been extended multiple times. At some point you either pro= file or start from scratch. =E2=80=8B
--bcaec50fe41faaaeb90545dcb990-- From nobody Wed Jan 11 18:51: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 CC31712946B for ; Wed, 11 Jan 2017 18:51:22 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 P7trm9hA4Pvd for ; Wed, 11 Jan 2017 18:51:21 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEC71293E9 for ; Wed, 11 Jan 2017 18:51:20 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id l2so817757wml.2 for ; Wed, 11 Jan 2017 18:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XG3Mk2VaTm0VmOf22+xdyj8e7vfzelye59r5kyF6hYA=; b=ddxwAc5yN72eOPWi048U9r4VmkU4bjflwNLeZufT4eqRaO8HGYClqWQ+6/O6SrmFRs CRznVLQ8K2d5baGICIS5bCBlrqZQB2wbUomOicI6qPE9zdRoWpsVDthRg4YozKFVOY2W mzClii4pvt0Nfav3u8vGVDN0lzKWLUo5gBb89OewYug9NUgUS+iVvanPeyuuXy7BHue/ kk6zGk3MUtKcvtivtEbMhkNy5Us54zawTRzJMsX4W4VE7BaSCk0fvLRmoIfPRThwr7Zq uSmuKu2EJtVfZFB4FOh5AASXadj3Os/Oy5tPWeGj9laCRvAwjSyqQCYPCgsaemNwxNHL CYhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XG3Mk2VaTm0VmOf22+xdyj8e7vfzelye59r5kyF6hYA=; b=Qp73Q+CD/JzpsGyd+hoa4X95LgeK2SdgELl9OaR7UJAJmlKAO/cLg3X5sd7v1Haiqq dEVTsTAjSFm387GaEOZk+4TOAC2fQk+3+38g1D5GekPYLURRXZrmVFSdUYaJ5mOhtdo2 T7dO3DXsSLcg2gQlu2Z7sEXZzqu3GcwK0D3Ssxgm/csrjn3X7xZFuwNMdM1MKlCjLToG UhBxI93ts2svEOl1BF4lS92KKf+3vGM97VXP1szWRcz8Ijhpk73cHHd4Cognt86pCBCk Xt1yyE/NknndHg6VRvSXBPLZoHE6p3JvG4Z1T9dfoRtGqEoHjTZgeUgID1Sn8fwwwbOq /TSw== X-Gm-Message-State: AIkVDXIATWrQKEoH7ve5aWd3/DUK/8sfojakvXMykxSY1WoCwVPsU+H1AJhUkwdvL4uCQz3wPpmDWQxVKHx4bg== X-Received: by 10.223.174.1 with SMTP id x1mr5587730wrc.126.1484189479264; Wed, 11 Jan 2017 18:51:19 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Wed, 11 Jan 2017 18:51:18 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 11 Jan 2017 21:51:18 -0500 X-Google-Sender-Auth: BSavAEXBvVxFioHfS3jC4rDAhnU Message-ID: Subject: Re: Using different crypto To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c1cd8b8b0e83e0545dccaca Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:51:23 -0000 --94eb2c1cd8b8b0e83e0545dccaca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2017 at 9:26 PM, Jana Iyengar wrote: > > In process control (i.e. SCADA) security, the concern is authenticity, no= t >> confidentiality. If you talk to process control folk they will often say >> that they don't want their packets to have encryption. They want >> authentication, not confidentiality. >> > > Unencrypted transport is not in scope for the wg. From > https://datatracker.ietf.org/wg/quic/charter/: "The QUIC working group > will provide a standards-track specification for a UDP-based, > stream-multiplexing, encrypted transport protocol ..." > > Unencrypted transport unfortunately leads to an ossified transport. > > =E2=80=8BThe WG scope says what the WG is to work on now. Nobody should eve= r read a charter to mean that the design must not be capable of extension to other use cases in the future. They do have good reason for not wanting encryption. It is more important to them to be able to debug their networks and stop their plan blowing up than to protect confidentiality. Security does not respond well to sloganeering or one size fits all solutions.=E2=80=8B --94eb2c1cd8b8b0e83e0545dccaca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Ja= n 11, 2017 at 9:26 PM, Jana Iyengar <jri@google.com> wrote:
=

In p= rocess control (i.e. SCADA) security, the concern is authenticity, not conf= identiality. If you talk to process control folk they will often say that t= hey don't want their packets to have encryption. They want authenticati= on, not confidentiality.

Unencrypted transport is not in scope f= or the wg. From=C2=A0https://datatracker.ietf.org/wg/quic/charter/:=C2=A0"The QUIC working group will provide a standards-track specifi= cation for a UDP-based, stream-multiplexing, encrypted transport protocol .= .."

Unencrypted transport unfortunately leads to an ossified transport.


=E2=80=8BThe WG scope says what the WG = is to work on now. Nobody should ever read a charter to mean that the desig= n must not be capable of extension to other use cases in the future.
<= div class=3D"gmail_default" style=3D"font-size:small">
They do have good reason for n= ot wanting encryption. It is more important to them to be able to debug the= ir networks and stop their plan blowing up than to protect confidentiality.= =C2=A0

Security does not = respond well to sloganeering or one size fits all solutions.=E2=80=8B
=
--94eb2c1cd8b8b0e83e0545dccaca-- From nobody Wed Jan 11 18:54:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4B6129461 for ; Wed, 11 Jan 2017 18:54:18 -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 DTSSks6nH2Fu for ; Wed, 11 Jan 2017 18:54:16 -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 AA6DA129406 for ; Wed, 11 Jan 2017 18:54:16 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id l19so4215141ywc.2 for ; Wed, 11 Jan 2017 18:54:16 -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=teL/uS2mMJSh/S55VyLnThU+2yPiEUkIEftMA0IglGw=; b=Kcdpc4VA00Mygf/bvVzIOLPE2QMGYX4PsPjeaE94GHM7MhZ5Jb6QwfoE7+v7MHSFxg KJBy+B0G7zz/QiAB1U7OdlQ+aQwMVwBPeWvfH8DKC/tWQsTz+FTqHqlpNnuwpNwyaFgD rt8AdXP0gwvwrCt4BpeFH1vBd27BlxRkhT8sbLtvnVqJutRhjWOIsdRhag/UtcFOpDpU 8X0R2E4ffw2n5h5TShKz46SPNso5SiLGvEk3IbkJ9F952HNbYsNpiGHET8qrcojRQyof P8KU5LFkFsol4cG8frCyKZqEwVMuddj6aZ0ZEy9EuehnaD2mkfzaIfneN38vgmQuUlMr INEA== 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=teL/uS2mMJSh/S55VyLnThU+2yPiEUkIEftMA0IglGw=; b=FMJjUR3J0uz0ZQcmVZQ7yfYbJrurJbRi8Dg748SDxsHiUJeX/ItoRUbF4F/AOEIZAA WTyVB5SYSpOMMnfECCYCyZ1SY1qn8EtYWG9Yie8ai7KiB8ABv9qO/xMFyXiue+juB1KN 01vne3RJfpp2pQk7qaCPKi87+w6h+n9mS1OuVtV/SHfaZILtWHqb/kodpq7uJWAGnFwU aHEasQrOjUb9kOWA+UjH6zyDnIxnnXFVfgWwJbugM5fw6yP08fGaastkyTk3LPG7Pzqn NkwIRJpUtP7vSxgmam8MGrAdRB8qM3Nvw/VGybCKn5IHQoraAkt4jdjBagcegfKkeePk ftew== X-Gm-Message-State: AIkVDXLVLlKfP8QXoakrU/oN1pR9BFny9yOM2newdIbfRJt3c58syq53uEXHIbLB0PgRK380fRqK2NFdrIK5bQ== X-Received: by 10.129.125.6 with SMTP id y6mr9519771ywc.234.1484189655873; Wed, 11 Jan 2017 18:54:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Wed, 11 Jan 2017 18:53:35 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 11 Jan 2017 18:53:35 -0800 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a1149482837eb310545dcd5b2 Archived-At: Cc: Mike Bishop , Ted Hardie , Phillip Hallam-Baker , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:54:18 -0000 --001a1149482837eb310545dcd5b2 Content-Type: text/plain; charset=UTF-8 +1. The charter is absolutely clear on this point. -Ekr On Wed, Jan 11, 2017 at 6:26 PM, Jana Iyengar wrote: > > In process control (i.e. SCADA) security, the concern is authenticity, not >> confidentiality. If you talk to process control folk they will often say >> that they don't want their packets to have encryption. They want >> authentication, not confidentiality. >> > > Unencrypted transport is not in scope for the wg. From > https://datatracker.ietf.org/wg/quic/charter/: "The QUIC working group > will provide a standards-track specification for a UDP-based, > stream-multiplexing, encrypted transport protocol ..." > > Unencrypted transport unfortunately leads to an ossified transport. > > --001a1149482837eb310545dcd5b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1. The charter is absolutely c= lear on this point.

-Ekr

On Wed, Jan 11, 2017 at 6:26 PM, Jana Iyengar <= jri@google.com><= /span> wrote:

In process control (i.e. SCADA) security, the concern is authe= nticity, not confidentiality. If you talk to process control folk they will= often say that they don't want their packets to have encryption. They = want authentication, not confidentiality.
Unencrypted transport = is not in scope for the wg. From=C2=A0https://datatracker.ietf.org/wg= /quic/charter/:=C2=A0"The QUIC working group will provide a standa= rds-track specification for a UDP-based, stream-multiplexing, encrypted tra= nsport protocol ..."

Unencrypted transport unfortunately leads to an ossifie= d transport.


--001a1149482837eb310545dcd5b2-- From nobody Wed Jan 11 18:54: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 9D24A126BF7 for ; Wed, 11 Jan 2017 18:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-yA1CJj1_dj for ; Wed, 11 Jan 2017 18:54:40 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0093.outbound.protection.outlook.com [104.47.37.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E8C129406 for ; Wed, 11 Jan 2017 18:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n+rh8VCFB3u3IPRI1dUJiDHY6PmXmwmiWn23abgd9Vw=; b=VXR0XKcinN53PHwJ5crP8mUffFg/1QLQcqyVy8b+7UcuQapVPsrA5rO/o9ScY9xWVASOYUgnbbJ0z/9tA3+Xb/UOD2hNotAQCuZB3x0vkn61hZ07w6C5z2IEaSs2exFoY5pa2TXKhdzgzsFMLJlxHb7e5mrLwFta2LP/JZXySac= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 02:54:38 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 02:54:38 +0000 From: Mike Bishop To: Phillip Hallam-Baker , Jana Iyengar Subject: RE: Using different crypto Thread-Topic: Using different crypto Thread-Index: AdJqwmguSJ5RH5YtRcG/iV7NxHADeQBeJWuAAAC914AAAI/MAAAAqlKAAAYr4GAAAK2xgAAA4/2AAATPSAAAADUNAAAAjnQAAADLZ4AAANywAAAAHcyW Date: Thu, 12 Jan 2017 02:54:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:600:8300:3b9a:2175:b98d:e538:f911] x-ms-office365-filtering-correlation-id: 4ab74241-ca9d-449e-e00f-08d43a96593c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:uMW6nLfVVXh6ynBdTIvhwkgM6IEdFFmEj7X4Kx9iXcra/qYJfB6dBcGhKLm5kLL3AgFZ1qHWKroja7HwlX1OJAOB0fUcIgQoWq5pxTlo2XXJvDNFoJPn3r4HtGriuW5ZdDrwCTqGT/2k9CWunjOVJGUs0jPJbxVB3KdCJZG5W8ZV11q7VAakxm9oW1QQIb/s6P91rPP8N7in+k8+0o2dlzyaXxbi4vTIEStjcGFFqiGAF08YsrpQ/54Kt27zX7P/f2zmGZj/gASLNTXKR55OT7Zqurx/DeIP8FV92sXcefiCYiOkBx5gebVcNKfhUOKmjzmN13ZCsfDdexQAKFqYi+PkO3+hox4ageQj39Ji+uOMQN23/fcGoMXVbkh1ohtLHMV/9WAgAScVs9n9dIOcsTLU+H6K2h6gVGTu2t1GwbDqFXE6pqrr++qvRJWDZCjyWn7G641+jwux3k6kNnfKQ9qzr4G91T92Y/1WPMVtz/g= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558021)(20161123555025)(20161123560025)(20161123564025)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(24454002)(189002)(377454003)(199003)(102836003)(33656002)(6116002)(10290500002)(189998001)(5005710100001)(10090500001)(8990500004)(3280700002)(68736007)(50986999)(3660700001)(54356999)(101416001)(3900700001)(76176999)(2906002)(106356001)(4326007)(7906003)(236005)(7736002)(74316002)(105586002)(54896002)(92566002)(2900100001)(9686003)(99286003)(93886004)(5660300001)(6306002)(2950100002)(5001770100001)(7696004)(7116003)(122556002)(97736004)(6436002)(38730400001)(8936002)(77096006)(25786008)(229853002)(3480700004)(81166006)(8676002)(54906002)(39060400001)(606005)(86612001)(6506006)(81156014)(55016002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708A2A7429D97E17BDB47E187790BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 02:54:38.0858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:54:41 -0000 --_000_BN6PR03MB2708A2A7429D97E17BDB47E187790BN6PR03MB2708namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree. However, I=92m not sure that quite fits the current discussion. = If the crypto protocol is factored out, the packet protection being done wi= th the keys it provides probably moves to the transport doc. In that case,= you would need to rev the transport protocol anyway to not encrypt packets= , if that was a desired property of a different QUIC version. Sent from my Windows 10 phone From: Phillip Hallam-Baker Sent: Wednesday, January 11, 2017 6:51 PM To: Jana Iyengar Cc: Martin Thomson; Mike Bishop; Ted Hardie; Salz, Ri= ch; Patrick McManus; = IETF QUIC WG; Martin Duke Subject: Re: Using different crypto On Wed, Jan 11, 2017 at 9:26 PM, Jana Iyengar > wrote: In process control (i.e. SCADA) security, the concern is authenticity, not = confidentiality. If you talk to process control folk they will often say th= at they don't want their packets to have encryption. They want authenticati= on, not confidentiality. Unencrypted transport is not in scope for the wg. From https://datatracker.= ietf.org/wg/quic/charter/: "The QUIC working group will provide a standards= -track specification for a UDP-based, stream-multiplexing, encrypted transp= ort protocol ..." Unencrypted transport unfortunately leads to an ossified transport. ?The WG scope says what the WG is to work on now. Nobody should ever read a= charter to mean that the design must not be capable of extension to other = use cases in the future. They do have good reason for not wanting encryption. It is more important t= o them to be able to debug their networks and stop their plan blowing up th= an to protect confidentiality. Security does not respond well to sloganeering or one size fits all solutio= ns.? --_000_BN6PR03MB2708A2A7429D97E17BDB47E187790BN6PR03MB2708namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I agree.  However, I=92m not sure that quite fi= ts the current discussion.  If the crypto protocol is factored out, th= e packet protection being done with the keys it provides probably moves to = the transport doc.  In that case, you would need to rev the transport protocol anyway to not encrypt packets, if that was a= desired property of a different QUIC version.

 

Sent from my Windows 10 phone

 

 



On Wed, Jan 11, 2017 at 9:26 PM, Jana Iyengar <jri@google.com&= gt; wrote:

In process control (i.e. SCADA) security, th= e concern is authenticity, not confidentiality. If you talk to process cont= rol folk they will often say that they don't want their packets to have enc= ryption. They want authentication, not confidentiality.

Unencrypted transport is not in scope for the wg= . From https://datatracker.ietf.org/wg/quic/charter/: &= quot;The QUIC working group will provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport pr= otocol ..."

Unencrypted transport unfortunately leads to an = ossified transport.


​The WG scope = says what the WG is to work on now. Nobody should ever read a charter to me= an that the design must not be capable of extension to other use cases in t= he future.

They do have good re= ason for not wanting encryption. It is more important to them to be able to= debug their networks and stop their plan blowing up than to protect confid= entiality. 

Security does not re= spond well to sloganeering or one size fits all solutions.​

--_000_BN6PR03MB2708A2A7429D97E17BDB47E187790BN6PR03MB2708namp_-- From nobody Wed Jan 11 19:37: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 E772512941E for ; Wed, 11 Jan 2017 19:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 hv3bgfjjVhyN for ; Wed, 11 Jan 2017 19:37:19 -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 69EA8129456 for ; Wed, 11 Jan 2017 19:37:17 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id i68so5616241uad.0 for ; Wed, 11 Jan 2017 19:37:17 -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=PRdjuOL/bEyMOtTvltGL0BkbtUdTFqVXotsXFSeVGwQ=; b=mudzvEtnpnE3LBPrwH7mjof86x7TMvJbwIaGsgpLVOpyw6roRPU+TSiNK0XA1SUEmV v/UqUokXqnvr5FB0MSaPOJdb+qEC3EKqNcAKFsodhxX+L+pH2J3BaaFNllqeZQ5IWtT+ ImhqB1+PKZZVtR2ZOskGPZI2VB0eYtRwyB5ELI/0WDrkEAIyL2e6bWcgbyvVyRbOiu0T UqIENldaDjLoViVwAusmwDbAWVYhbaDS/NxPOpICXWd9RB8SW4pSPuJLVXdUGaTGISwn Ve1duTtXM4M5Od/MF8lACjNW07zkv1VJ3I781OVPtHqtj3XW9KznmubA7adqRtAltUNK +0WQ== 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=PRdjuOL/bEyMOtTvltGL0BkbtUdTFqVXotsXFSeVGwQ=; b=dBn+rpSBSy6FNcZ0prQDpj+H8GkWzQi1l53E+s0FTQu/6mmx0JSWa1tdJ6aELmAjvP z5fkTV9eotTcBET+CaXJU2OSWjT6E6y54p9s5WFfkFziIJEHeeFqgPWELG21EhxBEUCY P4tCgVjCVZfB9+/7F+ivGD955osh+Ui4nJy7AU9yFeRdNPRs3g8aXDqbqgStRXNMepvw fRK9Q8H2Le7Quuj9b759PFTP3TLSubjwDMp4H4JOF/vdDfuIIlxsjbDSLdw7L3D7gN2m BuWpKCVt5+zvoowl3I0a6pRy/YasNTr2kadZa+D5mdicS6+JoZL1zFnTsClonGOj7fut Bi6Q== X-Gm-Message-State: AIkVDXIR6sGxueq3Spk2oHcQBvP+wUx87jXSBdNU53YdvZYx2U4ZOvg6y8WYCwdzVCprjbSksUl/2hOu8Jjv3ZJb X-Received: by 10.176.7.153 with SMTP id c25mr5496862uaf.154.1484192236410; Wed, 11 Jan 2017 19:37:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 19:37:15 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 19:37:15 -0800 Message-ID: Subject: Re: Using different crypto To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f403045f8a3c07c5280545dd6f95 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 03:37:21 -0000 --f403045f8a3c07c5280545dd6f95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > In the big PR on HTTP, BTW, the TLS restriction has been removed. If >>> people want it back, we certainly can, but I don't see a hard requireme= nt. >>> >> >> I don't understand what it means to remove the TLS restriction. It seems >> odd to have HTTP running on top of an encrypted transport but not have a >> TLS requirement. Is the idea that we could use something other than TLS = for >> HTTPS? >> > > =E2=80=8BYes. > > TLS is built with TCP in mind using 1990s crypto. It has been extended > multiple times. At some point you either profile or start from scratch. = =E2=80=8B > I wasn't clear: I was asking if we expect the use of HTTP in the HTTP mapping draft to expect anything other than TLS. My expectation is that if you use something other than TLS, then the HTTP mapping draft should change to reflect this. --f403045f8a3c07c5280545dd6f95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

In the big PR on HTTP, BTW, the TLS restriction has bee= n removed.=C2=A0 If people want it back, we certainly can, but I don't = see a hard requirement.


I = don't understand what it means to remove the TLS restriction. It seems = odd to have HTTP running on top of an encrypted transport but not have a TL= S requirement. Is the idea that we could use something other than TLS for H= TTPS?

=E2=80=8BYes.

=
TLS is built with TCP in mind using 19= 90s crypto. It has been extended multiple times. At some point you either p= rofile or start from scratch. =E2=80=8B

I wasn't clear:= I was asking if we expect the use of HTTP in the HTTP mapping draft to exp= ect anything other than TLS. My expectation is that if you use something ot= her than TLS, then the HTTP mapping draft should change to reflect this.
--f403045f8a3c07c5280545dd6f95-- From nobody Wed Jan 11 19:56: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 312B4129412 for ; Wed, 11 Jan 2017 19:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 6MqOYPkB1QBp for ; Wed, 11 Jan 2017 19:56:07 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5236129406 for ; Wed, 11 Jan 2017 19:56:07 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id i68so5825568uad.0 for ; Wed, 11 Jan 2017 19:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RmaH+x4j/kJChuEPPhhzJSzOebGXvmyhdJ1i1OQ4Ro8=; b=oc2A8KLtrEFXghxWA8oWwspjJ60DwzCF/gJGV8LoIjiEm38Xjb4xUzU+tIzMwJI/Ep N2CyCgNGGo4bvMvlM09ozp9K2WXQ8I9y8v+LnxdKd7OX9pLljNHr3EmiVg4rtPkPsQ/S i/FHz61+ZJNwWf17LZpUrzVDkMhm6sGzNyBY2ik+bUOlb4HVk8uOVetUHZh8RTFmBA9u awfMSPjstxuqa2oYdX3hifHU1VWj7zuMPmEMl1L7KqCSCGZh7kEvkuezc3s2Ibq/J2BL GMZS8FrF96GOekAqiSK6ktPM4FZ5APSDidnFf9cDoTEYPRZkzC86vfoHRyCGSgiilW2j W29g== 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=RmaH+x4j/kJChuEPPhhzJSzOebGXvmyhdJ1i1OQ4Ro8=; b=YjtJQZaxH90jRmFzX+an/svys632Wub/lN0WuoosWIkbh/W+PIUcyrJwETgiV5sEJm PiqmL5T3kGraqgYlpoAXZquLwP2NsgWITtYTddDbFB2DGwgHpx86R1E646ANUVFxcvxq JEOVdI19Z5qOQt2u/639v81V17o0XucRMFbo4uTDzZt00ypyZrImNCKBGT/1p0xxkfKK HGbQWhD2sGeMUcq7J+l92Ap5wr6sYjRJ9jEEnSsETcD09Bb15oR2bdpaa/MAePgMCwEV d2VCld8OGMdF/2RHaMffVNm1HQ6Syie4uj/vyTVQLsARX4CEI9wFwMwrHqWBQwckwlwk XlPw== X-Gm-Message-State: AIkVDXLwqo0aqqu56vQYyPlI5MR1DnCb6H2uyPZGgaI2hgz5zua+I9EJSfj/P6lxpJ2Ol/EQhgH9bNgF+pLMmiRL X-Received: by 10.176.84.211 with SMTP id q19mr4240951uaa.136.1484193366609; Wed, 11 Jan 2017 19:56:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 19:56:05 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 11 Jan 2017 19:56:05 -0800 Message-ID: Subject: Re: Using different crypto To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c1b10e46577310545ddb204 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 03:56:09 -0000 --94eb2c1b10e46577310545ddb204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > =E2=80=8BThe WG scope says what the WG is to work on now. Nobody should e= ver read > a charter to mean that the design must not be capable of extension to oth= er > use cases in the future. > That misses why encryption of QUIC was put in the charter in the first place. That wasn't to scope the problem, it was a pre-requisite for building a deployable and maintainable transport. If Google-deployed QUIC was not encrypted, it would have seen ossification by now. We would have no way to evolve it in the IETF, and this wg would be simply documenting it. They do have good reason for not wanting encryption. It is more important > to them to be able to debug their networks and stop their plan blowing up > than to protect confidentiality. > Monitoring is in the charter. The answer to monitoring is not "don't encrypt." Security does not respond well to sloganeering or one size fits all > solutions.=E2=80=8B > Agreed. Which is why we are relying on deployment experience and not expecting that QUIC will be used for everything in all cases. I'm happy that TCP's going to be around for situations where an encrypted transport cannot be used. --94eb2c1b10e46577310545ddb204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BThe WG scop= e says what the WG is to work on now. Nobody should ever read a charter to = mean that the design must not be capable of extension to other use cases in= the future.

That misses why encryption of QUIC was put in the charter in the first pla= ce. That wasn't to scope the problem, it was a pre-requisite for buildi= ng a deployable and maintainable transport.

If Goo= gle-deployed QUIC was not encrypted, it would have seen ossification by now= . We would have no way to evolve it in the IETF, and this wg would be simpl= y documenting it.

They d= o have good reason for not wanting encryption. It is more important to them= to be able to debug their networks and stop their plan blowing up than to = protect confidentiality.=C2=A0

Monitoring is in the charter. The answer to monitoring is not "d= on't encrypt."

=
= Security does not respond well to sloganeering or one size fits all solutio= ns.=E2=80=8B

Agreed. Whic= h is why we are relying on deployment experience and not expecting that QUI= C will be used for everything in all cases. I'm happy that TCP's go= ing to be around for situations where an encrypted transport cannot be used= .
=C2=A0

--94eb2c1b10e46577310545ddb204-- From nobody Wed Jan 11 21:30: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 7B0EF129415 for ; Wed, 11 Jan 2017 21:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 xe-O35Lo2vsg for ; Wed, 11 Jan 2017 21:30:37 -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 B1480126B6D for ; Wed, 11 Jan 2017 21:30:37 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id l7so8682873qtd.1 for ; Wed, 11 Jan 2017 21:30:37 -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=4L0Nd71VWnxtz0K9gQ3G+3p6dsqWxjgEaiWKaeEU/ZU=; b=HLzerGOXzPi736FFAnPSUFVX+XviYxYVJAPz0KHat48GOrFLNVXTEFvYnf4gYBEO6z KSwYB4oj6rBXStyu+b33H2xzqpCfCp4uNdJa0QMhkqwvoLXowYCQkBxmKNAXYcgJPaNd OTq7dRsbaFoo3FObmH8VgOAar4Rqp0o5nKSu7yQZINjaMe3+N15eyWVOZeDN6lp01zh+ TrX6z4eabxP6bpeBarDULnoBBT1VMB/1Xivo+HdIK/YcQ16VkIcF/qlAnuGRYXBAOk/r Gh2Oj01Z5vBC9/nkLV139vJi0CBQ5qNAmcUyBPLxVnmrCdZYT5Erp3cRf7iCoyJRWldq DpqA== 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=4L0Nd71VWnxtz0K9gQ3G+3p6dsqWxjgEaiWKaeEU/ZU=; b=pP03HrcEmbg9hlfpZ59a31sH7ZTDEC6fJ6alav0eFyHh1EGd18fU9vKbhE1BpHGax9 vNgOjEtx06JPQSIIn9Gm4cG/mh7fT0Q15DmfjnRKjvxHkXlJ6siGfNDqKfZtutWgcCrS /ztm8ETWu/cdhs868p1DfMehNN3ANF1OBZwMWmYXOt9IVj+1Hv6IEK/p2G4y5sD68Vtr rf98Dr/70pUywypzlp6rYyCnLdgjrj/M2uJCJWFzox0vyLnHDdfI+09Ntpj54SK/30wf 4PvoYXCNTjrPM2pJEK2FPmG+N+cl7wBDeuuTZ1FCiYCy9jnhitkiC17F0aziLZs1rX/q Z5eQ== X-Gm-Message-State: AIkVDXKm3P2AsD92Yka7K8p4vS6U14t1QmfNcAngmSo0esbUszI1N0pymTPEIVQBBnbTzuHql7VrDu7+hfssbg== X-Received: by 10.237.35.84 with SMTP id i20mr12386226qtc.247.1484199036648; Wed, 11 Jan 2017 21:30:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.182.66 with HTTP; Wed, 11 Jan 2017 21:30:06 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Wed, 11 Jan 2017 21:30:06 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1141b8065b06ea0545df045f Archived-At: Cc: Mike Bishop , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:30:39 -0000 --001a1141b8065b06ea0545df045f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2017 at 3:24 PM, Martin Thomson wrote: > On 12 January 2017 at 11:58, Ted Hardie wrote: > > If TLS 1.N (or 2.0) has a new handshake, I would prefer a world in which > > that can get described in a new version of quick-tls > > If we go with https://github.com/quicwg/base-drafts/pull/138 then TLS > N won't require changes to any document. > > If we go with a non-abstract description, I think that's a good pull request, but I think it's assuming the result of the abstraction discussion too much to try and close the discussion with it at this point. > Rather than continue to beat about the bushes - we're unlikely to find > any actual ponies there - let's ask the real question. You only plan > to replace something if you plan to replace it: do you want to replace > TLS? And why? > I _plan_ for replacing things when I see a history of those things getting replaced. In this particular case, we know that multiple applications may eventually run over this transport and they may have their own histories. If folks start running DNS over this, for example, I suspect someone will at least look at adapting DSNCrypt to work with QUIC. That particular example may not make come to pass, but hopefully it is illustrative of where our thinking apparently differs here. regards, Ted --001a1141b8065b06ea0545df045f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 11, 2017 at 3:24 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 12 January 2017 at 11:58, Ted Hardie <ted.ietf@gmail.com> wrote:
> If TLS 1.N (or 2.0)=C2=A0 has a new handshake, I would prefer a world = in which
> that can get described in a new version of quick-tls

If we go with https://github.com/quicwg/ba= se-drafts/pull/138 then TLS
N won't require changes to any document.


<= /div>
If we go with a non-abstract description, I think that's a go= od pull request, but I think it's assuming the result of the abstractio= n discussion too much to try and close the discussion with it at this point= .
=C2=A0
Rather than continue to beat about the bushes - we're unlikely to find<= br> any actual ponies there - let's ask the real question.=C2=A0 You only p= lan
to replace something if you plan to replace it: do you want to replace
TLS?=C2=A0 And why?

I _plan_ for replac= ing things when I see a history of those things getting replaced.=C2=A0 In = this particular case, we know that multiple applications may eventually run= over this transport and they may have their own histories.=C2=A0 If folks = start running DNS over this, for example, I suspect someone will at least l= ook at adapting DSNCrypt to work with QUIC.=C2=A0

That particular e= xample may not make come to pass, but hopefully it is illustrative of where= our thinking apparently differs here.

regards,

Ted
--001a1141b8065b06ea0545df045f-- From nobody Wed Jan 11 21:36: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 0BA9F129488 for ; Wed, 11 Jan 2017 21:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRwkjDWznVzK for ; Wed, 11 Jan 2017 21:36:00 -0800 (PST) Received: from mail-wj0-x243.google.com (mail-wj0-x243.google.com [IPv6:2a00:1450:400c:c01::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4922C129478 for ; Wed, 11 Jan 2017 21:36:00 -0800 (PST) Received: by mail-wj0-x243.google.com with SMTP id dh1so713125wjb.3 for ; Wed, 11 Jan 2017 21:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JA64DvHtIA6YXdsAnuE1/Titnw3zPFNtGOOYsvhVixU=; b=gtiz27uK5YRe14FlFMh6JsMC4Jad5vu6jtu+6kD0tBcgcB09FTrWIzd0MmvU/6TZ3J CJz0DK//gFh+cpyGObhB4DuVAUH7LmUMuHh6OkT/6GgAE+/eZRIL8lJ+d3AkJLPkS25P 2jsk977mVpkVn9w6L5G5vZ7k/ATYsXXo+CSsqm6zMsMjPcDmfDsCQvkccH3fWC1r/45p 7CcEQdbxiMOG61InlH1UMyUg23NVAxgPKXmnOwdFr/6xSqVyLTMDblOffF3xUGPrUWDC UHSiA+mU5UBHd996Ybsh0wIB8uSalm8JCL1KvRmUo6ykZ7GXKh5Z8bZjBTKz+i+f4sWM esvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JA64DvHtIA6YXdsAnuE1/Titnw3zPFNtGOOYsvhVixU=; b=jGzg3Ye2Y2i4BGppLRMU4R+39RciLpR9A3T1MZEByiJ8GinD6L08DsYIsthVkWogrd mPpGXx/qmXt/PHBGsHKUnI1MtXct1f4rV2kWAlzAosRwvFB4hmPjbN+hQZZYQwg+whNP R9Mb0RjcehKpH5mTVjNbQVpREwy9TWXVoBE8C8zAdoBd0YLdS1hUhDp8NONwE0x+bAoq wJqgnLQx+qBnoCS1tKuJpEythWNpg3lfP8ryCNxN+r6/Kd4iDaYXxL9ke8Y/N6KNvqtK opDKjWP3XTrWXu+7kY4OWrVTYaU+MQpQqpauyOYllzRPY6zw2ayr80ynmDpZCtOqjAht eUbg== X-Gm-Message-State: AIkVDXJrLvcIleltmBIg9fT6nyTEwuSf2kWxd05fxi2Rtnz5VuGDkMhmoB/GJMzdUlOBdwTu3p23JEJ7HCjeQQ== X-Received: by 10.194.187.103 with SMTP id fr7mr7033112wjc.99.1484199358635; Wed, 11 Jan 2017 21:35:58 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Wed, 11 Jan 2017 21:35:57 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 12 Jan 2017 00:35:57 -0500 X-Google-Sender-Auth: sEXYpPQ9ko6bHrpTok_PF6yeZx8 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar Content-Type: multipart/alternative; boundary=047d7bd6bc9c8c23a50545df17b2 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:36:02 -0000 --047d7bd6bc9c8c23a50545df17b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, I fully understand the reasons why a small unrepresentative monoculture with one perspective on a problem would insist on one solution. But that doesn't make it right. Putting encryption into things is not a way to prevent ossification. Modular design with clear separations of concerns is. Historically, IPSEC was a conformance requirement for IPv6 and vice versa. Then people realized that was a mistake. My preference is to encrypt at the transport, message and often at multiple levels inside the message layer. Your rhetoric really doesn't match your argument. You are arguing to ossify use of a 1990s protocol that is designed for one purpose and does it well. On Wed, Jan 11, 2017 at 10:56 PM, Jana Iyengar wrote: > =E2=80=8BThe WG scope says what the WG is to work on now. Nobody should e= ver read >> a charter to mean that the design must not be capable of extension to ot= her >> use cases in the future. >> > > That misses why encryption of QUIC was put in the charter in the first > place. That wasn't to scope the problem, it was a pre-requisite for > building a deployable and maintainable transport. > > If Google-deployed QUIC was not encrypted, it would have seen ossificatio= n > by now. We would have no way to evolve it in the IETF, and this wg would = be > simply documenting it. > > They do have good reason for not wanting encryption. It is more important >> to them to be able to debug their networks and stop their plan blowing u= p >> than to protect confidentiality. >> > > Monitoring is in the charter. The answer to monitoring is not "don't > encrypt." > > Security does not respond well to sloganeering or one size fits all >> solutions.=E2=80=8B >> > > Agreed. Which is why we are relying on deployment experience and not > expecting that QUIC will be used for everything in all cases. I'm happy > that TCP's going to be around for situations where an encrypted transport > cannot be used. > > > --047d7bd6bc9c8c23a50545df17b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No,= I fully understand the reasons why a small unrepresentative monoculture wi= th one perspective on a problem would insist on one solution. But that does= n't make it right.

Pu= tting encryption into things is not a way to prevent ossification. Modular = design with clear separations of concerns is.=C2=A0

Historically, IPSEC was a conformance requiremen= t for IPv6 and vice versa. Then people realized that was a mistake. My pref= erence is to encrypt at the transport, message and often at multiple levels= inside the message layer.=C2=A0

Your rhetoric really doesn't match your argument. You are argui= ng to ossify use of a 1990s protocol that is designed for one purpose and d= oes it well.=C2=A0


On Wed, Jan 11, 2017 at 10:56 PM, Jana Iyengar <jri@google.com> wrote:
=
=E2=80=8BThe= WG scope says what the WG is to work on now. Nobody should ever read a cha= rter to mean that the design must not be capable of extension to other use = cases in the future.

That misses why encryption of QUIC was put in the charter i= n the first place. That wasn't to scope the problem, it was a pre-requi= site for building a deployable and maintainable transport.

If Google-deployed QUIC was not encrypted, it would have seen ossi= fication by now. We would have no way to evolve it in the IETF, and this wg= would be simply documenting it.

They do have good reason for not wanting encrypti= on. It is more important to them to be able to debug their networks and sto= p their plan blowing up than to protect confidentiality.=C2=A0
<= /div>

Monitoring is in the charter. = The answer to monitoring is not "don't encrypt."

Security does not r= espond well to sloganeering or one size fits all solutions.=E2=80=8B
<= /div>

Agreed. Which is why we = are relying on deployment experience and not expecting that QUIC will be us= ed for everything in all cases. I'm happy that TCP's going to be ar= ound for situations where an encrypted transport cannot be used.
= =C2=A0


--047d7bd6bc9c8c23a50545df17b2-- From nobody Wed Jan 11 21:53: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 D079712943B for ; Wed, 11 Jan 2017 21:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 16A2pZEvffhG for ; Wed, 11 Jan 2017 21:53:17 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BE1129415 for ; Wed, 11 Jan 2017 21:53:17 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id l2so1384617wml.2 for ; Wed, 11 Jan 2017 21:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PFfJf+sJqkDT6Pm2Wh+vkQAWx369T9S9RBUX/2pM76E=; b=n04DfxswtYBnKbR1MLnbazuW87UApMOQo5Is+lq5xd9lDUfkMMM+CBhUCRE83xxNGW baY4bYNGmKDJJtGhbcPbSO9u9nnaF5z2Lqa8HYh5GBB4z5O+SfAdnssgiTVMxXV9CLZo ye93tu+i7UFrwuL1nVQ+r1k8zksocw37NnUKwov5gr8BPfLpYdqjTb5Gi6cAv+VlPAf1 hKvErwqYo1Ejnm2Nx2Y9aKkIQGY18xufbM7f/I9fiIova46QcGZqjipr/ZrMWFKo6WKN 7fQk8ocvP2T8Du6V8W0vGBwSoW+kGQKXUpuA8jE+9UYEr7kWsEy61qoLltDBkBgZ6nUZ oN3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PFfJf+sJqkDT6Pm2Wh+vkQAWx369T9S9RBUX/2pM76E=; b=Bx1221yc31UVuAPE0cznPTGEFRMa6B4s9Aw7rD8GnSvBhtG1oL+iK5iiRDyq5tXfaK M+PnIyFLoziGGFw2V34fWrtqCnq7sazI8Yj6qtocPaDumwcrCvkQ1BYsW528HBFr8jI8 VQPnqKkgBrMwRu0SF9xz3c4skJ/N+nFbcQ+w+wYe2FF2474fqm3zYjXvWrAMCILnqyno Db5aDMIh1qUaKl92cpjJfy/HysJue1zysMB4Y37Dfz0toGPUjcKkmIwauQ72enQWF4/w tHmU+UHNUHB1eJc6SF8pqxqxNXbj01qJQfPH1KJ3OCJT0nT7dfJlinLap7AatLNIXR81 W7/g== X-Gm-Message-State: AIkVDXKmtvnoZtcoFYzM8oHFszq9v39kRN1EcJOq0tqGZWxFFl2ABO/BXi1UA/MZL/TiwDOW1ooidM/XQNGRsA== X-Received: by 10.28.169.209 with SMTP id s200mr5165519wme.9.1484200395766; Wed, 11 Jan 2017 21:53:15 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Wed, 11 Jan 2017 21:53:14 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 12 Jan 2017 00:53:14 -0500 X-Google-Sender-Auth: gAxmup7DjKodHm25W3Qsiz51FOA Message-ID: Subject: Re: Using different crypto To: Ted Hardie Content-Type: multipart/alternative; boundary=001a114b414e5d823d0545df55e0 Archived-At: Cc: Mike Bishop , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:53:20 -0000 --001a114b414e5d823d0545df55e0 Content-Type: text/plain; charset=UTF-8 Another possible outcome is that we end up in an SSH/TLS situation. They were originally one protocol but they diverged as TLS was not willing to adapt to SSH demands or the SSH people particularly interested in participation. Having two QUIC like protocols that are slightly different for different purposes is not necessarily a disaster. But it is not something that should be casually accepted. A charter is not intended to allow people to say 'it says here that we can screw you, yah boo sucks'. The point of a charter is to allow work to get done by focusing on a narrow scope. But extensibility, layering and separation of concerns are always in scope. On Thu, Jan 12, 2017 at 12:30 AM, Ted Hardie wrote: > On Wed, Jan 11, 2017 at 3:24 PM, Martin Thomson > wrote: > >> On 12 January 2017 at 11:58, Ted Hardie wrote: >> > If TLS 1.N (or 2.0) has a new handshake, I would prefer a world in >> which >> > that can get described in a new version of quick-tls >> >> If we go with https://github.com/quicwg/base-drafts/pull/138 then TLS >> N won't require changes to any document. >> >> > If we go with a non-abstract description, I think that's a good pull > request, but I think it's assuming the result of the abstraction discussion > too much to try and close the discussion with it at this point. > > >> Rather than continue to beat about the bushes - we're unlikely to find >> any actual ponies there - let's ask the real question. You only plan >> to replace something if you plan to replace it: do you want to replace >> TLS? And why? >> > > I _plan_ for replacing things when I see a history of those things getting > replaced. In this particular case, we know that multiple applications may > eventually run over this transport and they may have their own histories. > If folks start running DNS over this, for example, I suspect someone will > at least look at adapting DSNCrypt to work with QUIC. > > That particular example may not make come to pass, but hopefully it is > illustrative of where our thinking apparently differs here. > > regards, > > Ted > --001a114b414e5d823d0545df55e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ano= ther possible outcome is that we end up in an SSH/TLS situation. They were = originally one protocol but they diverged as TLS was not willing to adapt t= o SSH demands or the SSH people particularly interested in participation.

Having two QUIC like proto= cols that are slightly different for different purposes is not necessarily = a disaster. But it is not something that should be casually accepted. A cha= rter is not intended to allow people to say 'it says here that we can s= crew you, yah boo sucks'. The point of a charter is to allow work to ge= t done by focusing on a narrow scope. But extensibility, layering and separ= ation of concerns are always in scope.

=C2=A0

On Thu, Jan 12, 2017 at 12:30 AM, Ted Hardie <ted.ietf@g= mail.com> wrote:
On Wed, Jan 11, 2017 at 3:24 PM, Martin Thomson <= span dir=3D"ltr"><martin.thomson@gmail.com> wrote:
On 12 January 2017 at 11:58, Ted Hardie <ted.ietf@gmail.com>= wrote:
> If TLS 1.N (or 2.0)=C2=A0 has a new handshake, I would prefer a world = in which
> that can get described in a new version of quick-tls

If we go with https://github.com/quicwg/base-drafts/pull/138 then TLS
N won't require changes to any document.


<= /div>
If we go with a non-abstract description, I think that'= ;s a good pull request, but I think it's assuming the result of the abs= traction discussion too much to try and close the discussion with it at thi= s point.
=C2=A0
Rather than continue to beat about the bushes - we're unlikely to find<= br> any actual ponies there - let's ask the real question.=C2=A0 You only p= lan
to replace something if you plan to replace it: do you want to replace
TLS?=C2=A0 And why?

I _plan_ for= replacing things when I see a history of those things getting replaced.=C2= =A0 In this particular case, we know that multiple applications may eventua= lly run over this transport and they may have their own histories.=C2=A0 If= folks start running DNS over this, for example, I suspect someone will at = least look at adapting DSNCrypt to work with QUIC.=C2=A0

That parti= cular example may not make come to pass, but hopefully it is illustrative o= f where our thinking apparently differs here.

regards,

Ted

--001a114b414e5d823d0545df55e0-- From nobody Wed Jan 11 21:55: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 DE1CE129488 for ; Wed, 11 Jan 2017 21:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, 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 XdM56vw4Tedq for ; Wed, 11 Jan 2017 21:55:54 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137F212943B for ; Wed, 11 Jan 2017 21:55:54 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id r136so6199482vke.1 for ; Wed, 11 Jan 2017 21:55:54 -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=kZtue4aPTQHHKvh5zOffFBJSXTPReCdVqgzx+ckTDoM=; b=EeT++NFk7uS+frgvuK+H1PToq9gSWPdvVh7VKJQxY3+9lJZIJd2qvJgu0R06e4Rms8 fSgDaMFIO2ugxNEV1BKZ8Ir2VWuxuCYt2e/6qT5e/Xs+Gqpn3W64NzbI884Ur2hNeUqn c8ZP9Cg0gDd5eSPOgk2NJG2cFWqM1mMMRdsA4nm5TA0gONB5ElujhQC3IPWe6TQDC4od bs52ONRgkOhZZPgHF0r0Sv6ORa4GO3XlOhOflWhT5lvQIZGXqjv+9J1pvKd+1j0kNJDq /0l2pri4nvughe9gZXU0vyip0K+yq/pxIr5FOwkzkiA3AEkCnreBiYWm+yg2Gb8lKyKZ M5zQ== 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=kZtue4aPTQHHKvh5zOffFBJSXTPReCdVqgzx+ckTDoM=; b=q4Qf5ttQJ6GjPwLPnzvcj8/FWvn4lyEFVt1coAi7l/x6vrrygmqwlTj+eTuRN4UB4M ipCcaj406bVKMgRt7BmhCZDXGWWB0TdBrmGwLyumm8BOpwPKrLN/SeCfo+tGm+eFZuxA +1mXY0mYJcawkCENM1fAR5lUfGNRN5+3bq126pKKpxFvg07+lntBlel2rfTRQ7dvdEo0 o9OVEtrAJCdp6El3NFfo3lKiPckzf6dtLt6HFdNJmiyqUP77Z+yu/LbdaCndC76A6Rs1 mjBQzRPgZ0TIFfBErQokH0OeYoWxIxoT0BC0oMLJpQ4YUDUNhoho1xSFWXApAho0JbMP nsXA== X-Gm-Message-State: AIkVDXLizySdr7HB2p9o70Xz4mIGSndrpYri8Hach6qg4ZQFnXh+58yIpS1XMDnDUFV8a221OfR75yioFN30Zbo/ X-Received: by 10.31.99.134 with SMTP id x128mr5924437vkb.161.1484200553000; Wed, 11 Jan 2017 21:55:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 11 Jan 2017 21:55:52 -0800 (PST) From: Jana Iyengar Date: Wed, 11 Jan 2017 21:55:52 -0800 Message-ID: Subject: Subject TBD (Branched from thread Re: Using different crypto) To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c07cff8bd07cb0545df5e32 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:55:56 -0000 --94eb2c07cff8bd07cb0545df5e32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm separating this thread out, since it seems to be a separate conversation. I'm also not sure what this topic is, so please rename the thread. On Wed, Jan 11, 2017 at 9:35 PM, Phillip Hallam-Baker wrote: > No, I fully understand the reasons why a small unrepresentative > monoculture with one perspective on a problem would insist on one solutio= n. > But that doesn't make it right. > Not being facetious: I honestly don't know what your point is. > Putting encryption into things is not a way to prevent ossification. > Modular design with clear separations of concerns is. > So, preventing others from reading/modifying bits does not prevent ossification, but designing for them them does? > Historically, IPSEC was a conformance requirement for IPv6 and vice versa= . > Then people realized that was a mistake. My preference is to encrypt at t= he > transport, message and often at multiple levels inside the message layer. > QUIC is a transport. We're talking about encrypting QUIC. We are not talking about encrypting below it. This is above UDP. > Your rhetoric really doesn't match your argument. You are arguing to > ossify use of a 1990s protocol that is designed for one purpose and does = it > well. > I'm quite certain that we are not talking about the same thing anymore. I'm talking about encrypting QUIC headers, and QUIC is not a 1990s protocol. What are you talking about? - jana On Wed, Jan 11, 2017 at 10:56 PM, Jana Iyengar wrote: > >> =E2=80=8BThe WG scope says what the WG is to work on now. Nobody should = ever read >>> a charter to mean that the design must not be capable of extension to o= ther >>> use cases in the future. >>> >> >> That misses why encryption of QUIC was put in the charter in the first >> place. That wasn't to scope the problem, it was a pre-requisite for >> building a deployable and maintainable transport. >> >> If Google-deployed QUIC was not encrypted, it would have seen >> ossification by now. We would have no way to evolve it in the IETF, and >> this wg would be simply documenting it. >> >> They do have good reason for not wanting encryption. It is more importan= t >>> to them to be able to debug their networks and stop their plan blowing = up >>> than to protect confidentiality. >>> >> >> Monitoring is in the charter. The answer to monitoring is not "don't >> encrypt." >> >> Security does not respond well to sloganeering or one size fits all >>> solutions.=E2=80=8B >>> >> >> Agreed. Which is why we are relying on deployment experience and not >> expecting that QUIC will be used for everything in all cases. I'm happy >> that TCP's going to be around for situations where an encrypted transpor= t >> cannot be used. >> >> >> > --94eb2c07cff8bd07cb0545df5e32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= 9;m separating this thread out, since it seems to be a separate conversatio= n. I'm also not sure what this topic is, so please rename the thread.

On Wed,= Jan 11, 2017 at 9:35 PM, Phillip Hallam-Baker <phill@hallambaker.com<= /a>> wrote:
No, I fully understand the reasons why a small= unrepresentative monoculture with one perspective on a problem would insis= t on one solution. But that doesn't make it right.





On Wed, Jan 11, 2017 at 10:56 PM, Jana Iyengar <jri@google.com> wrote:
=E2= =80=8BThe WG scope says what the WG is to work on now. Nobody should ever r= ead a charter to mean that the design must not be capable of extension to o= ther use cases in the future.

That misses why encryption of QUIC was put in the = charter in the first place. That wasn't to scope the problem, it was a = pre-requisite for building a deployable and maintainable transport.

If Google-deployed QUIC was not encrypted, it would have = seen ossification by now. We would have no way to evolve it in the IETF, an= d this wg would be simply documenting it.

They do have good reason for not wanting encryption= . It is more important to them to be able to debug their networks and stop = their plan blowing up than to protect confidentiality.=C2=A0

Monitoring is in the charter. Th= e answer to monitoring is not "don't encrypt."

Security does not respond well t= o sloganeering or one size fits all solutions.=E2=80=8B

Agreed. Which is why we are relying o= n deployment experience and not expecting that QUIC will be used for everyt= hing in all cases. I'm happy that TCP's going to be around for situ= ations where an encrypted transport cannot be used.
=C2=A0
<= /div>


--94eb2c07cff8bd07cb0545df5e32-- From nobody Wed Jan 11 21:59:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73031293F2 for ; Wed, 11 Jan 2017 21:59: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, 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 G3ilzgnoMZ71 for ; Wed, 11 Jan 2017 21:59:03 -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 43B9112943B for ; Wed, 11 Jan 2017 21:59:03 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id u143so11720836oif.3 for ; Wed, 11 Jan 2017 21:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dl1gswXJJXFAaL2pBFG7YcpmTw2d8VKyxVds71ctASU=; b=B7PD8Qo+iy7pprUy0u2HP1p6/aRYs+5HzMgs+RZcr7uRPI8EMiK1lNlUK/ieyeFDVE kCkqXE4qngTaMhjz0njfriplpQeYsmSS57FHAOqO4rk6s1xzb5IXrt/OjNbJKBs2fyJm jtx7r1rQEgyLTnrTNxIsJZAxuy2r70oW1H0JXHbT/nAwC+4aAWszlP9qyaNex2jQRhMj hklMWwG7dhbUN+WL8UedAqZKMkvZEQFwlIhmcaGepNRJyuy3ut1h2HPCabKCFUmRc8oF ab93DU9dgAbIlhbspzbafo6VLN7DwlS9AYD9H9ucwsZL6C2eOv/p8+pYtU0qTmXEm5fQ YTrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dl1gswXJJXFAaL2pBFG7YcpmTw2d8VKyxVds71ctASU=; b=nZJGMeCyJiPYmiCxiib/Qynp5AtDu5xby50zVPhAvy/W9/9Aj4O0HwniAzTYKdD33I YTVBNa09qxHpdDhHFcVAAh5nji1m7JKypIqpgdJfI3H8XwqNl/ZL0C8PSd4OpdD1iBUY ZCwiOvoTTz/Xwr8+B1Is/0jt8ywkwLh6aIuG/JifcIgEHmpeqqtpM1vtGN82bPAJt9iz 3QWTEcmbBGkKRIGQsABt+5NUE2NM7lPVS+fegKLx6Lap79AYKyuJov4xAl9MEe+LLYsJ 5XAL3XH+K2D+/7ruDRAJ/37DWojraJOY4DFYjX+c1GjOddxT8K9iL9ISy6dP4WIt4dUx 3Rtw== X-Gm-Message-State: AIkVDXL8AySH6yGagSDdR6cmA9d0EXE69a/lO4cLmpNxjc+HJe5/DKl1SZe9d5QGu5DOO6Gw4tHaQw+RbbJ3Lw== X-Received: by 10.157.23.195 with SMTP id j61mr6339898otj.187.1484200742623; Wed, 11 Jan 2017 21:59:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Thu, 12 Jan 2017 05:58:52 +0000 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar , Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c094b180a25bc0545df6a88 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:59:05 -0000 --94eb2c094b180a25bc0545df6a88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jana, can you elaborate as to why unencrypted Google QUIC would have ossified by now? I cannot connect that argument, and must be missing something basic. To be clear, I am not suggesting that this iteration of QUIC should allow unencrypted traffic. I am providing an example, to answer Martin's question, of something our IETF successors might want to do other than use TLS 1.x. The immediate impact is to make the transport document as crypto-agnostic as possible. On Wed, Jan 11, 2017 at 7:56 PM Jana Iyengar wrote: > =E2=80=8BThe WG scope says what the WG is to work on now. Nobody should e= ver read > a charter to mean that the design must not be capable of extension to oth= er > use cases in the future. > > > That misses why encryption of QUIC was put in the charter in the first > place. That wasn't to scope the problem, it was a pre-requisite for > building a deployable and maintainable transport. > > If Google-deployed QUIC was not encrypted, it would have seen ossificatio= n > by now. We would have no way to evolve it in the IETF, and this wg would = be > simply documenting it. > > They do have good reason for not wanting encryption. It is more important > to them to be able to debug their networks and stop their plan blowing up > than to protect confidentiality. > > > Monitoring is in the charter. The answer to monitoring is not "don't > encrypt." > > Security does not respond well to sloganeering or one size fits all > solutions.=E2=80=8B > > > Agreed. Which is why we are relying on deployment experience and not > expecting that QUIC will be used for everything in all cases. I'm happy > that TCP's going to be around for situations where an encrypted transport > cannot be used. > > > > > --94eb2c094b180a25bc0545df6a88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jana, can you elaborate as to why unencrypted Google QUIC would have o= ssified by now? I cannot connect that argument, and must be missing somethi= ng basic.

To be clear, I am not suggesting that th= is iteration of QUIC should allow unencrypted traffic. I am providing an ex= ample, to answer Martin's question, of something our IETF successors mi= ght want to do other than use TLS 1.x. The immediate impact is to make the = transport document as crypto-agnostic as possible.

On Wed, Jan 11, 2017 at 7:56 PM Jana Iyengar <jri@google.com> wrote:
=E2=80=8BThe WG sc= ope says what the WG is to work on now. Nobody should ever read a charter t= o mean that the design must not be capable of extension to other use cases = in the future.

That misses why encryption of QUIC was put in= the charter in the first place. That wasn't to scope the problem, it w= as a pre-requisite for building a deployable and maintainable transport.

If Google-deployed QUIC was not encrypted, it would have seen ossif= ication by now. We would have no way to evolve it in the IETF, and this wg = would be simply documenting it.

They do have= good reason for not wanting encryption. It is more important to them to be= able to debug their networks and stop their plan blowing up than to protec= t confidentiality.=C2=A0

Monitoring is in the charter. The answer to moni= toring is not "don't encrypt."

Security does not respond well to sloganeering or one size fits all solu= tions.=E2=80=8B

Agreed. Which is why we are relying on deployment experie= nce and not expecting that QUIC will be used for everything in all cases. I= 'm happy that TCP's going to be around for situations where an encr= ypted transport cannot be used.
=C2=A0
<= /div>


--94eb2c094b180a25bc0545df6a88-- From nobody Wed Jan 11 22:00: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 D8441129491 for ; Wed, 11 Jan 2017 22:00:32 -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 DMioiVtFXBUj for ; Wed, 11 Jan 2017 22:00:31 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7B0129479 for ; Wed, 11 Jan 2017 22:00:31 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id w204so11986825oiw.0 for ; Wed, 11 Jan 2017 22:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LiqBbWF2pMyKPzRl3mWGfe1CqAkCGY8BIHOngovUqwc=; b=iDYuQjqONyfURZInjEXcnr6coN9SMZZ4CEv4B+Qa0whg3k7f/oKuD3ISzlZyBnYT66 A7xx1usGIRs9FsdkG5td+7ePR0hg+vsMLKgrXCa24Nmy0gfdcy1qzNUbLB8t60q0KIkV gzEBXmHytPQE/o6iDxmnlnXOurt2wldygk8zk0mVn3HwIgs4joVO1DqVmknlQoC7cL/C dwZAFiWCmCax+G0l2F6MtOByGJ5k2uZfGhQubAU+iWj3YsbFbdmRjDk/Iz7J6tP21u3W UMeccK1GYwbj+e3xZI3xCCV6ZqXB8rqh39m2CTbNrUMdzdPNZja+4DO+AIBS5oCKGAj5 mHPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LiqBbWF2pMyKPzRl3mWGfe1CqAkCGY8BIHOngovUqwc=; b=ZFhBdHEaLwcfxaNwCygel2SuGG9Zv0uaPsJLOE1iibnvctGCt8txcnsuzHSY4qUdHJ +L4d/61RO1p+7MWpRlyUjoRwZS/gase90QehD3F/BLorCKaI10FnqOC9LDbTklB1vCIl cOr1qkqTbRn5QHEdhZJJKi54dksKgMMbrerU5NKzuTXPnJeXIeG5tWVYurJpkJTXHPxe 4B2XErkTFxPjZg4DiAi66HBJb76rzQf9QCFdyd9qFlz+IWNF6ioAwXRAQV7gK22vcz2A UEdqJywRulavCv0bNlaL1BZMcsn0OlLDmO9wqn7n3jNLi3/k9DkgGjO1UzU2oc5clvMM jYDg== X-Gm-Message-State: AIkVDXJTEBwD7Lt6F3RL3d7uRc5T/Yx+4DvjMohfexox6F59tK5VxkMuh+Zgg2LpqpfX2ZOJKc3OiD0QNsOzdg== X-Received: by 10.157.33.122 with SMTP id l55mr5747523otd.151.1484200830723; Wed, 11 Jan 2017 22:00:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Thu, 12 Jan 2017 06:00:20 +0000 Message-ID: Subject: Re: Using different crypto To: Jana Iyengar , Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a114178944a6c8f0545df6f22 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 06:00:33 -0000 --001a114178944a6c8f0545df6f22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, never mind. I see now that the encryption is needed to block middlebox nonsense. On Wed, Jan 11, 2017 at 9:58 PM Martin Duke wrote= : > Jana, can you elaborate as to why unencrypted Google QUIC would have > ossified by now? I cannot connect that argument, and must be missing > something basic. > > To be clear, I am not suggesting that this iteration of QUIC should allow > unencrypted traffic. I am providing an example, to answer Martin's > question, of something our IETF successors might want to do other than us= e > TLS 1.x. The immediate impact is to make the transport document as > crypto-agnostic as possible. > > On Wed, Jan 11, 2017 at 7:56 PM Jana Iyengar wrote: > > =E2=80=8BThe WG scope says what the WG is to work on now. Nobody should e= ver read > a charter to mean that the design must not be capable of extension to oth= er > use cases in the future. > > > That misses why encryption of QUIC was put in the charter in the first > place. That wasn't to scope the problem, it was a pre-requisite for > building a deployable and maintainable transport. > > If Google-deployed QUIC was not encrypted, it would have seen ossificatio= n > by now. We would have no way to evolve it in the IETF, and this wg would = be > simply documenting it. > > They do have good reason for not wanting encryption. It is more important > to them to be able to debug their networks and stop their plan blowing up > than to protect confidentiality. > > > Monitoring is in the charter. The answer to monitoring is not "don't > encrypt." > > Security does not respond well to sloganeering or one size fits all > solutions.=E2=80=8B > > > Agreed. Which is why we are relying on deployment experience and not > expecting that QUIC will be used for everything in all cases. I'm happy > that TCP's going to be around for situations where an encrypted transport > cannot be used. > > > > > --001a114178944a6c8f0545df6f22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, never mind. I see now that the encryption is needed to block mi= ddlebox nonsense.

On Wed, Jan= 11, 2017 at 9:58 PM Martin Duke <martin.h.duke@gmail.com> wrote:
Jana, can you elaborate as to why unencry= pted Google QUIC would have ossified by now? I cannot connect that argument= , and must be missing something basic.

To be clear, I am not sugg= esting that this iteration of QUIC should allow unencrypted traffic. I am p= roviding an example, to answer Martin's question, of something our IETF= successors might want to do other than use TLS 1.x. The immediate impact i= s to make the transport document as crypto-agnostic as possible.

On Wed, Jan 11, 2017 at 7:56 PM Jana Iyengar= <jri@google.com> wrote:
=E2=80=8BThe WG scope says what the WG is to work on now. Nobody sh= ould ever read a charter to mean that the design must not be capable of ext= ension to other use cases in the future.

That misses why enc= ryption of QUIC was put in the charter in the first place. That wasn't = to scope the problem, it was a pre-requisite for building a deployable and = maintainable transport.

If Google-deployed QUIC was not encrypted= , it would have seen ossification by now. We would have no way to evolve it= in the IETF, and this wg would be simply documenting it.
=

They do have good reason for not wanting encryption. It is m= ore important to them to be able to debug their networks and stop their pla= n blowing up than to protect confidentiality.=C2=A0

<= /div>
Monitoring is in the = charter. The answer to monitoring is not "don't encrypt."

Security does not respond well to sloganeerin= g or one size fits all solutions.=E2=80=8B

Agreed. Which is why we are re= lying on deployment experience and not expecting that QUIC will be used for= everything in all cases. I'm happy that TCP's going to be around f= or situations where an encrypted transport cannot be used.
=C2=A0



--001a114178944a6c8f0545df6f22-- From nobody Thu Jan 12 01:23: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 B4B891294D1 for ; Thu, 12 Jan 2017 01:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 kl7H3d4vrGW8 for ; Thu, 12 Jan 2017 01:23:13 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E1E129440 for ; Thu, 12 Jan 2017 01:23:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,349,1477983600"; d="scan'208";a="168890219" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx143-out.netapp.com with ESMTP; 12 Jan 2017 01:13:06 -0800 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 12 Jan 2017 01:18:08 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 12 Jan 2017 01:18:08 -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=wlUD5T8TjCDH54/Ek6kshpx1TI7eArXu2PWjJOnIRMw=; b=cHwxcfGtm2QdDhjSDAmXECRog/HfC4AVaEHZEsP+eK5ZwIc/z5YIB8QZKaeuQFS3pMGCSsHecDPLgpvOG277qQEh5WsUsR3vZL2OFRzJU47L2yoKjvQ8fCwa8HLDGPbN0iKEgmy5GxsjXgXF801Yqgh1Z0tG/DECgyZhIxv1J5s= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 12 Jan 2017 09:18:08 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0803.021; Thu, 12 Jan 2017 09:18:08 +0000 From: "Eggert, Lars" To: Brian Trammell Subject: Re: How fiddly should the QUIC header be? Thread-Topic: How fiddly should the QUIC header be? Thread-Index: AQHSbB/hFPBw7CkZokmsekzH2Fl046E0kVKA Date: Thu, 12 Jan 2017 09:18:08 +0000 Message-ID: References: <234A0F1A-494D-4A1A-8A94-43550614A0B2@trammell.ch> In-Reply-To: <234A0F1A-494D-4A1A-8A94-43550614A0B2@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 9c4915c7-91a3-4afd-06df-08d43acbec3b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1156; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:rAo/go0BVxDmmIyEsldyBbwK4B0qg7ygbDp6jEjXCu03H9dPi3giSAQd824EKE8xc5xgNNKnkc0wws7YEGcQTSEgrILmjnl5bYijdIy1Uq355butQUPkdodJKGguHoeiptBTqxBsES6Sph3SVVjnbWUxEugQRtpY9ClxEus1vaugsZzNA7XpOt0iNTDGI8tOdiLK/eY9fdRL6ib2arCpAe9WvECCdAsr0+9h8hFDy7PYJYX8NeTIJ17LkOsd89wLuUVLG7GXAIVjBkYQeT3Ibhszg163/Jkabaljh4jMnOTTBI33Xy6MM/zJiyrZ6EfYySg7hT3oLXC3TxGNb65WxLWdwhHJ5i2xqL7mH7P10dtqbFgrhiDCnrI1bMN0eVtQwAgORrknMFhxv95GorzQxdr9hVB73XZRWKETH28q+zdsZKOlZ+dld0nsCPUv74/iA1awGtQO7cOEmD0UHOFuuQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(377424004)(199003)(189002)(6512007)(4001150100001)(122556002)(82746002)(7736002)(3280700002)(305945005)(2950100002)(110136003)(6916009)(6306002)(4326007)(83716003)(2906002)(50226002)(189998001)(3846002)(99286003)(102836003)(97736004)(6116002)(86362001)(68736007)(57306001)(81166006)(8936002)(33656002)(8676002)(81156014)(101416001)(76176999)(66066001)(50986999)(229853002)(6506006)(25786008)(92566002)(2900100001)(6436002)(3660700001)(105586002)(106116001)(36756003)(106356001)(38730400001)(6486002)(5660300001)(77096006)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 09:18:08.0875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:23:15 -0000 Hi, (chair hat off) On 2017-1-11, at 16:31, Brian Trammell wrote: > I would suggest reducing the number of possible header layouts to reduce = complexity, based on the following observations and assumptions: I do share this sentiment (see https://github.com/quicwg/base-drafts/issues= /40). And it's not only the common header; the various frame type headers h= ave a similar plethora of field length options. Lars= From nobody Thu Jan 12 01:49: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 4A3E01294C8 for ; Thu, 12 Jan 2017 01:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGBfWYzdkyl3 for ; Thu, 12 Jan 2017 01:49:15 -0800 (PST) Received: from trammell.ch (unknown [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CC7A51293F8 for ; Thu, 12 Jan 2017 01:49:14 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id EF4A21A067E; Thu, 12 Jan 2017 10:49:11 +0100 (CET) Subject: Re: How fiddly should the QUIC header be? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A13F41FB-1896-4ADE-8F36-4A5A4A5CA789"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Thu, 12 Jan 2017 10:49:11 +0100 Message-Id: <5B221815-CB97-40F9-ABE3-FC14EAE25404@trammell.ch> References: <234A0F1A-494D-4A1A-8A94-43550614A0B2@trammell.ch> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:49:16 -0000 --Apple-Mail=_A13F41FB-1896-4ADE-8F36-4A5A4A5CA789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 12 Jan 2017, at 10:18, Eggert, Lars wrote: >=20 > Hi, >=20 > (chair hat off) >=20 > On 2017-1-11, at 16:31, Brian Trammell wrote: >> I would suggest reducing the number of possible header layouts to = reduce complexity, based on the following observations and assumptions: >=20 > I do share this sentiment (see = https://github.com/quicwg/base-drafts/issues/40). And it's not only the = common header; the various frame type headers have a similar plethora of = field length options. Agreed. I chose to focus on the packet header first for a couple of reasons. = First, I've spent more time looking at it recently in the context of = draft-kuehlewind-quic-appman (see Mirja's message). Second, reducing the = attack surface presented by packet header parsing code seems more = critical than reducing the attack surface presented by frame parsing = code; the later requires an attacker to be able to establish a = cryptographic session with a target, while the former merely requires an = attacker to be able to send a UDP packet to the target. (The use of magic numbers or other techniques in order to ensure that an = initial packet can't be forged through reflection/amplification is = probably an issue we should discuss separately from overhauling the = header, though the solution might come in the same PR. I'll go ahead and = file in github.) Cheers, Brian --Apple-Mail=_A13F41FB-1896-4ADE-8F36-4A5A4A5CA789 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYd1EXAAoJEIoSt78L6kajPowQAIGTmwRNfQxG3S3Kkj95iOhG 81rESw/d7GeSUrzy3oNSOwD+JpMRZ7LRFLA6Pc/MVlq0EEIraseMtZplHnLyUU4Q CHjoOnH7yT1fPCrhZNSURo+uhg0U/9r/ekGjYV2pgG2+6xCGBY4GkCOrXJRQJ3Ne 2Am3vGzcxFoFz0xYvG10De5X2hUpwq+SsrJTpVQAkg3WZNjmbGf9hEPc/G9A6nKx /rOR+halz2nu1bn3m7fjsK6kBN+R99wSbsUI+LZ3PBU0QS+Wn0SW8jYSwaHzLRmI 03nfkcyUphjPeZdhS6aUGwyJ5BQMEWAQPSKdjsi7v0DSUb+gNiejbBEE2TC6Q8Qk k7qN9JSMf2HlmNOGKl62TpRV4ZBa22/b/4Qf238sZpaVnPY7ACFeXKbtdLtT6V63 hRpvhvRKYMeM2K2HrkO0na6j6gLHlcwX5CxOxuGPF9HfyO/OLQwYSotI73MPO3Ap 9RjwE7AgeO/ivyv7Z5J4Unhim/z2D8YQ5fMOONvV0I8AooSIqbUMC2E8LfYX/YjL r6u+VOYOYq/EMGqLM6D9Db0eouUm6VEf0NIlXIh703DMq3TIYlIDBWz9qjY4v/Qx guB8RZlGnM1kfJuFRYioyPyTjyM/x04f6LCwbqnxd+NiGGFUPDy0xMof7f8JYbCa XA5w9q+hIQ/O0wO9z82w =a5UK -----END PGP SIGNATURE----- --Apple-Mail=_A13F41FB-1896-4ADE-8F36-4A5A4A5CA789-- From nobody Thu Jan 12 01:49: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 5B20C1293F8 for ; Thu, 12 Jan 2017 01:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 4Bd0GoJP3xeg for ; Thu, 12 Jan 2017 01:49:28 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CBB127058 for ; Thu, 12 Jan 2017 01:49:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3tzgvn1xLRzMl1L; Thu, 12 Jan 2017 10:49:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSINMkYOsgF4; Thu, 12 Jan 2017 10:49:24 +0100 (CET) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 12 Jan 2017 10:49:24 +0100 (CET) Subject: Re: New Version Notification for draft-kuehlewind-quic-appman-00.txt To: quic@ietf.org References: <148415378146.8207.1206867835191640996.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <85318cdf-c598-9f8a-60fa-90a69b56942a@tik.ee.ethz.ch> Date: Thu, 12 Jan 2017 10:49:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148415378146.8207.1206867835191640996.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:49:31 -0000 Hi all, we submitted a first version of a draft on applicability and manageability of quic. This draft is of course by far not complete, also given how much the protocol is still changing. The idea is to evolve this draft in parallel to the protocol design. Of course any feedback, comments and additional contributions are welcome! Please send PRs or comments to the list! As this draft is an individual draft, this is not part of the wg github. You can find the draft here: https://github.com/mami-project/draft-kuehlewind-quic-appman Mirja and Brian On 11.01.2017 17:56, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-kuehlewind-quic-appman-00.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. > > Name: draft-kuehlewind-quic-appman > Revision: 00 > Title: Applicability and Management of the QUIC Transport Protocol > Document date: 2017-01-11 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-appman-00.txt > Status: https://datatracker.ietf.org/doc/draft-kuehlewind-quic-appman/ > Htmlized: https://tools.ietf.org/html/draft-kuehlewind-quic-appman-00 > > > Abstract: > This document discusses the applicability and manageability of the > QUIC transport protocol, focusing on caveats impacting application > protocol development and deployment over QUIC, and network operations > involving QUIC traffic. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Thu Jan 12 13:20:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3DC129443 for ; Thu, 12 Jan 2017 13:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156] 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 VqBuWa-JXRJh for ; Thu, 12 Jan 2017 13:20:41 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (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 35D231289C4 for ; Thu, 12 Jan 2017 13:20:41 -0800 (PST) Received: from [172.16.141.20] ([46.183.103.8]) by mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MMHDp-1cOCpl0fYz-007yXl; Thu, 12 Jan 2017 22:20:36 +0100 From: "Dirk Kutscher" To: "Eggert, Lars" Subject: Re: How fiddly should the QUIC header be? Date: Thu, 12 Jan 2017 22:20:31 +0100 Message-ID: <06639B53-873A-4C96-93B5-3D4DB79D5D24@dkutscher.net> In-Reply-To: References: <234A0F1A-494D-4A1A-8A94-43550614A0B2@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate Trial (1.9.6r5307) X-Provags-ID: V03:K0:QNDu9E7KpgFyMcNClaFPvXlg5Pc2Z+TE97qJzdFQpNnOIJW7HLP bIq+o9/6hvTQ3Q593BWwNOeGGpEOVLstUEBT613RFdxtCHd7doOJwYfYGbgpKffoP9LrTgM 9FzdXAetoZXY+MbT9OfgLnUhG620tj2434Bbs0wpli7ddso0BixcQ+fgxQy4wP2kwyL0VtI TnJe5IUnUuTYdXggCqSEw== X-UI-Out-Filterresults: notjunk:1;V01:K0:JlDq9otVu+o=:lvD44745PGmXztjtpltyMW eYEcF3mkd1qpDvk/lsqoHHLAfiMtkM2Em2FSw7+I1i8Gqf/Mb18lgndZIsVicI+Eg+5UROJyX dnjSbrWGbxcMWLGbXkKdLJ5/xj4EQmEBwdbTLYNPqScnkV8i8Bk9ALP1n8oGxNahu3FmsoWq0 BbnAPoxNCkq+9LgjsvfSarziAGVo493WbEm3IRgFILhwQhjZZfayR92u8OORsfBoStPgj71Hb YMOF2zpo3ZXjGPJ1oMYjKkN9H1rh8+D6/TPA8Z2OmxjJCu6WK0QKhDx1h60X1V7MHH1mvcl0F dAU3LUGgbW52gNU1pRa8T9VDBWWZ7iJaWL9nuNtQNJlIA6T+EZ0v2FyomZNbxYRzJH0HGNvkf 0ChqK2KpF07w38iivH6TqoDuQ8PoW3EXrdAcCgNFsUM4zjhTt1idg0Kc0LZHcG59VJqvh+lai 4iBI4cpeQy/oZfMdLhVK6CGepeMS6LCPIfrf8LuZUXCtTdf1mDJ8hVgsoCWRrjMtjAEu0sgGR 49UIMpONjWbf+5QSpoFeJrMlO1G4J+P3qJC6zb7vcuW/EYHzIRdTfMGmox8iJI41e7LIHESnk vQp416Me7iarI0sIvlAkGlwPsZ/C+GtCLh6K3PQuIQTCY1MkEvaXgcCVeDo3EB43VxySi/qFu BdoedgMbzCFLYbUYBhihX0+sRivxQV8vTI0wyV7TF4tK4gJdnY3Yba3JrNcrBAZwUgfXSRohg rZ+Zj9tmwkYYQGnn Archived-At: Cc: Brian Trammell , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:20:43 -0000 Hi, On 12 Jan 2017, at 10:18, Eggert, Lars wrote: > On 2017-1-11, at 16:31, Brian Trammell wrote: >> I would suggest reducing the number of possible header layouts to >> reduce complexity, based on the following observations and >> assumptions: > > I do share this sentiment (see > https://github.com/quicwg/base-drafts/issues/40). And it's not only > the common header; the various frame type headers have a similar > plethora of field length options. Yes, I had the same thoughts. Dirk From nobody Thu Jan 12 19:12: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 4F03A129955 for ; Thu, 12 Jan 2017 19:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 s8TIy2ZWROoW for ; Thu, 12 Jan 2017 19:12:36 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1A8129951 for ; Thu, 12 Jan 2017 19:12:35 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id s140so42092041qke.0 for ; Thu, 12 Jan 2017 19:12:35 -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=fxyPjAiYRIhSoFqaKS1S1d3Zw217uDivEZ+ddhIwLMA=; b=Tl5SU/pJ5RhxQL78MTigmlKDLv+zWWxnZ7vuHI5Zxai8w7i0pkwed7Bt4EtLkSup3R rwDiRSAl8oKaCDpWu7Shlw8z9W2tzWXNZVpEIOeSf1Fz0rYjVbjpYkGCThz6b5V+hO+F MNFHxBwRO47IapjZ9zLjo3/Qe2/f+tkj9fFYBEwbuSCMNS3VaMx4EgxWOClIXFzhTrdx CPKmItKf1f2KAzuzYpyUXWFfnnEvwsq3W2R28gT9AjmmLLgdPUjFXs5weM8p9GzMjq9t QJ62SNrf5Ct02Gk3y7t7u7DQgzVK+uJjqN8aicDdkDSuFBlsrWsbD6MflejVMk6GKPKm C4yw== 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=fxyPjAiYRIhSoFqaKS1S1d3Zw217uDivEZ+ddhIwLMA=; b=dRcCGK5AL4SEA+DFfnAWd+lWtafTHoQcHHGwvGzyw3LhE/dHvacIgjLQHgt1urTJ7s 7+6VueVQr7A1u+A3UUi6RCntAU8lRSd25MA2OkuFZiHM8DoHAC/UBMhEyWZjh74e4lQ7 TUuRI3ulgh6+XBfiGTLUFC/q9nO4S3jI7WZeGlgD9SN6ag4z9LlTMb6FfsE3mhLl60v3 H8UZZqrTS2TmMY0Qkl4xRKFWomdkxjwmOuX9zU7B3Syi6R8BoCAfehf0yylJc6D/UOv7 rfwNt1muk1nbGNS9piDP+qq647Za5v2tcavEe/aQg/USHoHGbh8wRIeUpy0Tcinfn4w+ fA2A== X-Gm-Message-State: AIkVDXISGEEss78xUF/s8ih02qIaQUj1JDB8c/6vWb0xaKJf9d5UyhGhMS3p0y8mlUYY8fh2joRGtPxNkQQUzQ== X-Received: by 10.233.235.66 with SMTP id b63mr17955015qkg.144.1484277155097; Thu, 12 Jan 2017 19:12:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 12 Jan 2017 19:12:34 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 13 Jan 2017 16:12:34 +1300 Message-ID: Subject: Re: Using different crypto To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 03:12:37 -0000 On 12 January 2017 at 18:30, Ted Hardie wrote: > I _plan_ for replacing things when I see a history of those things getting > replaced. In this particular case, we know that multiple applications may > eventually run over this transport and they may have their own histories. > If folks start running DNS over this, for example, I suspect someone will at > least look at adapting DSNCrypt to work with QUIC. I think that we are largely disagreeing on the nature of the plan and the degree of up-front work. Both plans hinge on defining a new QUIC version number, so - as I said before - it's largely a matter of paper shuffling. I would rather let those future people deal with a little more work, especially given that P < 1 of that ever happening. Like I said, YAGNI applies. From nobody Thu Jan 12 20:01:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A721299AA for ; Thu, 12 Jan 2017 20:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 4MXevhzqF6Bt for ; Thu, 12 Jan 2017 20:01:24 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC831299A9 for ; Thu, 12 Jan 2017 20:01:24 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id r126so48349409wmr.0 for ; Thu, 12 Jan 2017 20:01:24 -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=F3J32wYrphOfzZ4Tb9rFGEJJSs9WIYPI1vfKRY2i6FE=; b=Jd8a74FG1zJn8pB81TXvGu78mHsaU7Wat+p1wh04tV2DDEmqG938LFSCk7YjYuhQ/M COL190F9J/h7djn947k7DCZPc7GNaC+JrsCHqIVoV/vLyfAkxlfCR0hl1+RRzdCXQqd6 g6CWO89nwM8NDZ1Pb7H9SLqrJCsZvV35QVGyNwANteN3/DYK240F6IE8FwtkrwCrLTVE VnSqWL6QaepteuzZ/4TWb0AL0M+dQ4xWFZEL3xscIU64Gx1KLD8tWF7FQb4dyVde8DY3 vJBc8+O/PNAWGVYMUXnUd03ItbHeYdWVT75XxuXBiW+U77WjQEJJ8PPEnyfcQZlN+QU0 7c6w== 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=F3J32wYrphOfzZ4Tb9rFGEJJSs9WIYPI1vfKRY2i6FE=; b=cveNKIaM7oYj2d9ORJyAgfn2HEI5DPjqPUvJ9tiEemoD5hOUKLUpYBDFWJ2/X5xrE/ tHWYADicDpRhlXubabHEXNxSTyfbwFvi5hCHgyFkRxGDhE+k8WzInWaYhJKftLzmaUhZ T6ukM02YKmPAf17pb8ojhOcubN89G8j1biClvoqytGTpVIGR4qPeJIrbE8FyZ+83jiJN 3kRSD9iazh9QfzFrXbqpmpsDWchUXreJywTFYfP99OC/OsjpP5BuXOIZSNbGEqcD7KUW GHRSvlhD+RfVqmS1OdA7Z9nN0MUa7t4LFoaroj5KXGn4Ffsbr+rNLhY8MX5WkVStWgq6 XoLQ== X-Gm-Message-State: AIkVDXJ8P1ozA9mkJUWPN8H5+A4/By1A2oCkmTlzMxHFr8ybwl4iZgnqTVnTUkxq9OgWJ8Wo1mDg3rzwPizP0CnQ X-Received: by 10.223.167.130 with SMTP id j2mr11471832wrc.154.1484280082749; Thu, 12 Jan 2017 20:01:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.4 with HTTP; Thu, 12 Jan 2017 20:01:21 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 12 Jan 2017 20:01:21 -0800 Message-ID: Subject: Re: Using different crypto To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c1cdad61496c10545f1e386 Archived-At: Cc: Mike Bishop , Ted Hardie , "Salz, Rich" , Patrick McManus , Jana Iyengar , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 04:01:26 -0000 --94eb2c1cdad61496c10545f1e386 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2017 at 7:12 PM, Martin Thomson wrote: > On 12 January 2017 at 18:30, Ted Hardie wrote: > > I _plan_ for replacing things when I see a history of those things > getting > > replaced. In this particular case, we know that multiple applications > may > > eventually run over this transport and they may have their own historie= s. > > If folks start running DNS over this, for example, I suspect someone > will at > > least look at adapting DSNCrypt to work with QUIC. > > I think that we are largely disagreeing on the nature of the plan and > the degree of up-front work. Both plans hinge on defining a new QUIC > version number, so - as I said before - it's largely a matter of paper > shuffling. I would rather let those future people deal with a little > more work, especially given that P < 1 of that ever happening. > > Like I said, YAGNI applies. > =E2=80=8BI should mention that internal to Google we are already using QUIC= with a different handshake protocol, one which keys are delivered out-of-band.=E2= =80=8B It has been a vision from the very early days of QUIC that the handshake protocol could be swapped out. (And of course we're doing this in the "QUIC crypto" to TLS 1.3 conversion). As such, I strongly agree with Mike's option #2. --94eb2c1cdad61496c10545f1e386 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 1= 2, 2017 at 7:12 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
= On 12 January 2017 at 18:30, Ted Hardie <ted.ietf@gmail.com> wrote:<= br> > I _plan_ for replacing things when I see a history of those things get= ting
> replaced.=C2=A0 In this particular case, we know that multiple applica= tions may
> eventually run over this transport and they may have their own histori= es.
> If folks start running DNS over this, for example, I suspect someone w= ill at
> least look at adapting DSNCrypt to work with QUIC.

I think that we are largely disagreeing on the nature of the plan an= d
the degree of up-front work.=C2=A0 Both plans hinge on defining a new QUIC<= br> version number, so - as I said before - it's largely a matter of paper<= br> shuffling.=C2=A0 I would rather let those future people deal with a little<= br> more work, especially given that P < 1 of that ever happening.

Like I said, YAGNI applies.

=E2= =80=8BI should mention that internal to Google we are already using QUIC wi= th a different handshake protocol, one which keys are delivered out-of-band= .=E2=80=8B It has been a vision from the very early days of QUIC that the h= andshake protocol could be swapped out. (And of course we're doing this= in the "QUIC crypto" to TLS 1.3 conversion). As such, I strongly= agree with Mike's option #2.=C2=A0

--94eb2c1cdad61496c10545f1e386-- From nobody Fri Jan 13 01:30: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 07A7912951A for ; Fri, 13 Jan 2017 01:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbUoU2pHtpmj for ; Fri, 13 Jan 2017 01:30:53 -0800 (PST) Received: from trammell.ch (unknown [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 420B01294A5 for ; Fri, 13 Jan 2017 01:30:53 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 67ACC1A151C; Fri, 13 Jan 2017 10:30:51 +0100 (CET) Subject: Re: How fiddly should the QUIC header be? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8FFB0038-739E-4859-B9AD-B4AEFEB68762"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <06639B53-873A-4C96-93B5-3D4DB79D5D24@dkutscher.net> Date: Fri, 13 Jan 2017 10:30:50 +0100 Message-Id: References: <234A0F1A-494D-4A1A-8A94-43550614A0B2@trammell.ch> <06639B53-873A-4C96-93B5-3D4DB79D5D24@dkutscher.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Eggert, Lars" , Dirk Kutscher X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 13 Jan 2017 09:30:55 -0000 --Apple-Mail=_8FFB0038-739E-4859-B9AD-B4AEFEB68762 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Filed in GitHub; see https://github.com/quicwg/base-drafts/issues/147 = and https://github.com/quicwg/base-drafts/issues/148 Cheers, Brian > On 12 Jan 2017, at 22:20, Dirk Kutscher wrote: >=20 > Hi, >=20 >=20 > On 12 Jan 2017, at 10:18, Eggert, Lars wrote: >=20 >> On 2017-1-11, at 16:31, Brian Trammell wrote: >>> I would suggest reducing the number of possible header layouts to = reduce complexity, based on the following observations and assumptions: >>=20 >> I do share this sentiment (see = https://github.com/quicwg/base-drafts/issues/40). And it's not only the = common header; the various frame type headers have a similar plethora of = field length options. >=20 > Yes, I had the same thoughts. >=20 > Dirk --Apple-Mail=_8FFB0038-739E-4859-B9AD-B4AEFEB68762 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYeJ5LAAoJEIoSt78L6kajaD4QAL9n41ArAuX7b+1R18EID78x cK4kYJVnTW4ypFtwB846F/uvK+iHpuP+wzchL6z5n4mGrWGimXZsiLg7xsBt1ehW Its95O2DaRpG2fRYup8cE+jE+RqbQM82BpdDsFG8qemKMl+UPkJoHONMORQN2HMI oPLNyWp1t6tgREfLugk8E+XS41Y1EDDbzyPzqGxO3ulCHGYZtNiYoMAvj9mPK++8 ZPmqXt7h7rpUKFXCiqH8ENawLQfzVTSXWPFC7nrWYWS3xyeBAL2+vL+1W5QMxJB7 EV9NDLxxO2HS/PCfQ+GFkHYZ2BaJHqKaBfsCzmZ9uTF4bSApRYoAty2oSAcUUOtQ +b67pSAuzRHBCdf8Ki02ZCxJu8yVxj8o6vpImJkQMPSPbodp0/Il1ku+3Okt0uYA ps6qtGxwzbHoyRK7/abfOAp1lDXlWsGFaYOLa58MrJH/YVv4ZARJKlp1s2mcOKNR uOxtErrKO+FU8BI3SmYe5jdPmeMfDT5Y1gAsWempC9rZzwa7W15U2DuZbr/9Nwc/ xmIbDtYFXUs47j34qkgY3PDwdQtXIkj97Ry3mpeH0rWbKVbKtlO0TRKI4idpkfXm mBo40C95LPvE33mSUjNdfflM4LLp8sJXdxiErOEKvcUZMgSaUydOME7XfDBOzMHN FK02LaeIjVyWGCyTXU1A =EzhQ -----END PGP SIGNATURE----- --Apple-Mail=_8FFB0038-739E-4859-B9AD-B4AEFEB68762-- From nobody Sat Jan 14 10:31:33 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 58CF812987C; Sat, 14 Jan 2017 10:31:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-transport-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148441869236.24158.13881489980168067227.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 10:31:32 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 18:31:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-01.txt Pages : 47 Date : 2017-01-14 Abstract: QUIC is a multiplexed and secure transport protocol that runs on top of UDP. QUIC builds on past transport experience, and implements mechanisms that make it useful as a modern general-purpose transport protocol. Using UDP as the basis of QUIC is intended to address compatibility issues with legacy clients and middleboxes. QUIC authenticates all of its headers, preventing third parties from changing them. QUIC encrypts most of its headers, thereby limiting protocol evolution to QUIC endpoints only. Therefore, middleboxes, in large part, are not required to be updated as new protocol versions are deployed. This document describes the core QUIC protocol, including the conceptual design, wire format, and mechanisms of the QUIC protocol for connection establishment, stream multiplexing, stream and connection-level flow control, and data reliability. Accompanying documents describe QUIC's loss recovery and congestion control, and the use of TLS 1.3 for key negotiation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-transport-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-01 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 Sat Jan 14 10:45:56 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 98DBB129C9C; Sat, 14 Jan 2017 10:45:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-recovery-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148441955162.24124.11096637218074764490.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 10:45:51 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 18:45:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-01.txt Pages : 13 Date : 2017-01-14 Abstract: QUIC is a new multiplexed and secure transport atop UDP. QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport. QUIC implements the spirit of known TCP loss detection mechanisms, described in RFCs, various Internet-drafts, and also those prevalent in the Linux TCP implementation. This document describes QUIC loss detection and congestion control, and attributes the TCP equivalent in RFCs, Internet-drafts, academic papers, and TCP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-01 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 Sat Jan 14 10:46:13 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 43060129D12; Sat, 14 Jan 2017 10:46:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-tls-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148441956426.24112.11788973670436218925.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 10:46:04 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 18:46:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-01.txt Pages : 32 Date : 2017-01-14 Abstract: This document describes how Transport Layer Security (TLS) can be used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic . Working Group information can be found at https://github.com/quicwg ; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/tls . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-tls-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-01 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 Sat Jan 14 10:46:26 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 753AA129D10; Sat, 14 Jan 2017 10:46:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-http-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148441957647.24183.9829444579490046353.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 10:46:16 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 18:46:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-01.txt Pages : 25 Date : 2017-01-14 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. Specifically, this document identifies HTTP/2 features that are subsumed by QUIC, and describes how the other features can be implemented atop QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-http-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-01 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 Sun Jan 15 19:08: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 8122D12944B for ; Sun, 15 Jan 2017 19:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR3v02RA0pWJ for ; Sun, 15 Jan 2017 19:08:24 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F898129466 for ; Sun, 15 Jan 2017 19:08:24 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4566E22E1F3 for ; Sun, 15 Jan 2017 22:08:16 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: QUIC Interim Meeting - registration closing, dietary requirements From: Mark Nottingham In-Reply-To: <114989C2-6FCF-4C7F-B5C0-0CCE3276B325@mnot.net> Date: Mon, 16 Jan 2017 14:08:13 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <59D0F39D-8E11-4E67-BCC4-085F85958BDF@mnot.net> References: <114989C2-6FCF-4C7F-B5C0-0CCE3276B325@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Mark Nottingham List-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, 16 Jan 2017 03:08:26 -0000 Reminder - if you haven't sent dietary requirements yet, please do so = ASAP (within the next two days). > On 6 Jan 2017, at 5:23 pm, Mark Nottingham wrote: >=20 > Hi everyone, >=20 > If you intend on participating in our upcoming interim meeting (onsite = or remotely), please register as per the arrangements page ASAP: >=20 > = https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangeme= nts.md >=20 > As that page states, registration closes two weeks beforehand, which = is 10 January Tokyo time -- i.e., 9 January in many North and South = American time zones. >=20 > If you're registered to participate onsite and have dietary = restrictions, please send them to me by replying to this e-mail (not to = the list!) as soon as possible. >=20 > Kind regards, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jan 15 23:26: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 B22F4126D73 for ; Sun, 15 Jan 2017 23:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 MAzKgJhApdfU for ; Sun, 15 Jan 2017 23:26:08 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33171293DF for ; Sun, 15 Jan 2017 23:26:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,238,1477983600"; d="scan'208";a="176931898" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 15 Jan 2017 23:16:03 -0800 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 15 Jan 2017 23:21:03 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sun, 15 Jan 2017 23:21:03 -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=GAxxR6yCgmAbCPrfcsquItQTqh63dDnxZL2Io9Mfc3g=; b=T94UNXZrchX+DL0DHGhsC0qZTom2pYVFSWpqSOn9jcWu06UkAp3uPLrMaChJ373CpG0yHeNvYn5AG053ez8G5+5zl3P/X0u4QY3Hsz/3p+LfjHXtT/ybi9aAYBF6Q1a4ltqz4O3csZxxqhVpaX4yKzZg0eKRAlgZ1MMiXa/TTrk= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Mon, 16 Jan 2017 07:21:03 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0803.021; Mon, 16 Jan 2017 07:21:03 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Re: Preparations for Tokyo interim Thread-Topic: Preparations for Tokyo interim Thread-Index: AQHSa+ShWOAek67VWU60wXlUvxdtYqE6umUA Date: Mon, 16 Jan 2017 07:21:02 +0000 Message-ID: <9AF171B1-953B-405D-B429-9CC21395C9C0@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:31a8:301:a1ac:9268:525a:92b5] x-ms-office365-filtering-correlation-id: 4b9d9dbb-055c-4d6c-ce82-08d43de03a89 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1156; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:dYaPIS42YwFdFROPPOnLTkcSu9IMiB0kW2SYMgmdWHN/Bw8BZ5LbiEAisxf+Z03vrdszJ79Ku/9I28mLNdS9iI5+eQk34ap3QFV5LDp6xIhenk+g6YKktUV2acR26UecuwQqzy0xCqKitvo+LU5Z2jGg8KH7HDY9VXL547T42MAw6M807vv2QzBHbDWszzfAYc2qH0+5kTY2TyV12I4Oo+yhYL9FifU7fBJP7iEjN+YC70FL1Sb/uBBArOx/etucm6jKMw6PXqrIAD9NIIx5AWI4VzG2V47OrtN/hXBvTkTJNOggusFyIojUG7cKGRhxlhAJcNqEQUpI91hdpwhWKjjbcc0udsQmXJ9bJ6/wyDqx//abi0759+a8c7E5/3eFRdwIjFC/nrUnC2qV86eMGpQW6u8sxtMzRlCz/ooD8qCJxLjA8fCtk0IV00sm0cZhOgLO4CujmphhGF5Hp1xpUw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(46034005)(189002)(199003)(377424004)(24454002)(3480700004)(86362001)(229853002)(2900100001)(106356001)(57306001)(81166006)(81156014)(68736007)(105586002)(2906002)(50226002)(101416001)(76176999)(50986999)(92566002)(8936002)(8676002)(106116001)(110136003)(102836003)(6116002)(305945005)(450100001)(107886002)(4001150100001)(6916009)(5660300001)(99286003)(6512007)(36756003)(97736004)(6306002)(122556002)(189998001)(6486002)(2950100002)(6436002)(6506006)(3660700001)(83716003)(38730400001)(25786008)(7736002)(3280700002)(82746002)(33656002)(77096006)(27001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.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: text/plain; charset="us-ascii" Content-ID: <77A1BA6F181BBF43AC8A1098AF2D38B2@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2017 07:21:02.7973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 07:26:10 -0000 Hi, On 2017-1-11, at 9:28, Eggert, Lars wrote: > *** By this weekend***, the editors should prepare and submit new revisio= ns of the core specs, and label issues in GitHub as follows: as you have probably seen, new revisions of the core documents have been po= sted. Thanks to the editors for the timely turn-around. > For any open issues where it is the editors' judgement that there is cons= ensus emerging on a resolution, they should incorporate that into the ID re= visions. Please label any such issues in GitHub (maybe with "confirm-consen= sus" or something similar.) Here is the list of the "confirm-consensus" issues: https://github.com/quic= wg/base-drafts/issues?utf8=3D%E2%9C%93&q=3D%20label%3Aconfirm-consensus%20 WG participants should check that they agree with the respective proposed r= esolutions included in the new revisions. We'll move through these fairly r= apidly during the interim. (Obviously, if you disagree with the classificat= ion itself, i.e., believe something here needs more discussion, speak up AS= AP.) > For any open issues where it is the editors' judgment that more discussio= n is needed to come to consensus on a resolution, they should NOT make any = textual changes to the new revisions. Please label any such issues in GitHu= b (maybe with "needs-discussion" or something similar.) Here is the list of "needs-discussion" issues: https://github.com/quicwg/ba= se-drafts/issues?utf8=3D%E2%9C%93&q=3Dlabel%3Aneeds-discussion%20 We'll spend the bulk of the interim time on these issues. WG participants s= hould familiarize themselves with the different respective options and be p= repared to discuss these during the interim. Mark and me will post a rough agenda for the interim once we've had a chanc= e to sync up after the weekend. The WG should be prepared that the agenda w= ill be rather flexible, given that we're trying to make best use of the mee= ting time and will reallocate time as needed to make good progress overall. Lars= From nobody Tue Jan 17 16:08: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 561D9128AC9 for ; Tue, 17 Jan 2017 16:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwfsVDAOZq42 for ; Tue, 17 Jan 2017 16:08:00 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40C912711D for ; Tue, 17 Jan 2017 16:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v8RNL4eOT7PB3wxDGAk2LXzFW/7Q2JYSAjvzbYjs6bE=; b=AcnfDMZTWzEELDf/azVWWGjBlGcMnj0Je7NF44s007gNZLPhxuSz5+/lb0tyHXwrFRcAoKgwmLf1LNSD26CdxjOi/DA2oX4tJYUUGbVmu1zY6KEjc78g4I8tObPN2UwfMX9TDOCvdpiyp9JQh1n7n83TFD+4dXJmsQN/88iChdc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 18 Jan 2017 00:07:58 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0845.013; Wed, 18 Jan 2017 00:07:58 +0000 From: Mike Bishop To: IETF QUIC WG Subject: FW: New Version Notification for draft-bishop-quic-http-and-qpack-01.txt Thread-Topic: New Version Notification for draft-bishop-quic-http-and-qpack-01.txt Thread-Index: AQHScR38qy/GgUo6fUWbv/Z48maJxqE9Wlhw Date: Wed, 18 Jan 2017 00:07:57 +0000 Message-ID: References: <148469766991.32074.16605318271142170510.idtracker@ietfa.amsl.com> In-Reply-To: <148469766991.32074.16605318271142170510.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:1::f0] x-ms-office365-filtering-correlation-id: 86937a7c-18d7-4b29-bd75-08d43f360f21 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:OyQlk1NkHeaSas6LfXD0n3UbSEIvV7+jQ/vXrYojIi6QZGk9eSopNuHWDQfhZkkri8tUHEsCDmEFWsdAMrXG/3r+r1ktm1Y10LX++auvzv4gbRONVaZaFUm7mypq6Cig/kOKDe7hY0U2+lufnz9yR5kewthyRg4EIT7pfbCYe+uGO6i/HSsLb18ZAkJEYir8n+rOPkymxOYNQNSI6x3pZvYgEmeBylxXFYqDVrAUNDmMEe22mTmr1gI3KBPLQBNzM4FaOzfK48xB/LgUWI6lx/ZWCHSkZRtnHb3Pn0p1tCo2/pwW9y8gnCIN0LqO8ntdzTm6IpQeuOibJ+Xdq7ioyjtOaYX6zcRXlcrPFrjxuio9ZgJeFkgC/VlROEHDmBIB0VHdrs9FrF1oi6YNF8uyZZNRecvUak2uWzMJxTWiaLykpW9A29BRzSgkuuEg/0om8IgbtpVq+XEEFoYGr2RBy01r92NTz4m11FoyISo5YEM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558021)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39450400003)(39850400002)(39860400002)(39840400002)(13464003)(189002)(377454003)(199003)(377424004)(10710500007)(122556002)(606005)(6506006)(68736007)(229853002)(8936002)(38730400001)(7906003)(8990500004)(8676002)(2473003)(6916009)(450100001)(74316002)(33656002)(86362001)(81166006)(2900100001)(86612001)(53936002)(55016002)(7736002)(6436002)(77096006)(81156014)(9686003)(230783001)(189998001)(110136003)(5660300001)(102836003)(97736004)(2950100002)(76176999)(54356999)(99286003)(50986999)(10090500001)(10290500002)(7696004)(107886002)(3660700001)(5005710100001)(3280700002)(2420400007)(54896002)(7110500001)(25786008)(15650500001)(2906002)(236005)(790700001)(101416001)(105586002)(106116001)(92566002)(6306002)(106356001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27086B368C567F3C950E67D1877F0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 00:07:58.0065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 00:08:02 -0000 --_000_BN6PR03MB27086B368C567F3C950E67D1877F0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aCB0aGUgcmVjZW50IHB1YmxpY2F0aW9uIG9mIHRoZSBXRyAtMDEgZHJhZnRzLCBJJ3ZlIHVw ZGF0ZWQgbXkgUVBBQ0sgZHJhZnQgdG8gLTAxIGFzIHdlbGwuICBOb3RhYmxlIG5vbi1lZGl0b3Jp YWwgY2hhbmdlczoNCg0KICAqICAgUmVhbGl6ZWQgd2UgZGlkbuKAmXQgbmVlZCB0aGUgYWJpbGl0 eSBmb3IgdGhlIGVuY29kZXIgdG8gZGVjbGFyZSBhIHRhYmxlIHNpemUgaWYgdGhlIGVuY29kZXIg aXMgZXhwbGljaXRseSBtYW5hZ2luZyB0aGUgdGFibGUuICBUaGVyZWZvcmUsIEkgY2FuIHN0ZWFs IHRoZSDigJxzaXplIGNoYW5nZeKAnSBpbnN0cnVjdGlvbiByYXRoZXIgdGhhbiB0aGUg4oCcbmV2 ZXItaW5kZXhlZOKAnSBpbnN0cnVjdGlvbi4gIFJlc29sdmVzIG9uZSBvZiB0aGUgbWFqb3IgZHJh d2JhY2tzLg0KICAqICAgUmVtb3ZlZCB0aGUgcHJvcG9zZWQgSFRUUC9RVUlDIG1hcHBpbmcsIHNp bmNlIHRoYXTigJlzIG5vdyBsYXJnZWx5IGluY29ycG9yYXRlZCBpbnRvIHRoZSBXRyBkb2N1bWVu dC4gIFJlcGxhY2VkIHdpdGggYSBtdWNoIHNob3J0ZXIgc2VjdGlvbiBvbiBob3cgdG8gc2xvdCBR UEFDSyBpbnRvIGhxLTAxLg0KICAqICAgQ2xhcmlmaWVkIGhvdyBjaGFuZ2VzIHRvIG1heGltdW0g dGFibGUgc2l6ZSBkdXJpbmcgYSBsaXZlIGNvbm5lY3Rpb24gYXJlIGhhbmRsZWQsIGVzcGVjaWFs bHkgaW4gbGlnaHQgb2YgdGhlIHNldHRpbmdzLXN5bmNocm9uaXphdGlvbiB0ZXh0IHRoYXTigJlz IGJlZW4gYWRkZWQgdG8gaHEtMDEuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxNyA0OjAxIFBNDQpUbzogTWlr ZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAx LnR4dA0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaXNob3AtcXVpYy1o dHRwLWFuZC1xcGFjay0wMS50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBNaWtlIEJpc2hvcCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpO YW1lOiAgICAgICAgICAgICAgICAgIGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrDQoN ClJldmlzaW9uOiAgICAgICAgICAgICAgMDENCg0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAg IEhlYWRlciBDb21wcmVzc2lvbiBmb3IgSFRUUC9RVUlDDQoNCkRvY3VtZW50IGRhdGU6ICAgICAg ICAgICAgICAgMjAxNy0wMS0xNw0KDQpHcm91cDogICAgICAgICAgICAgICAgICBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAgICAgICAgICAgICAgIDEwDQoNClVSTDogICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmlzaG9wLXF1 aWMtaHR0cC1hbmQtcXBhY2stMDEudHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay8NCg0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3At cXVpYy1odHRwLWFuZC1xcGFjay0wMQ0KDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAxDQoN Cg0KDQpBYnN0cmFjdDoNCg0KICAgSFRUUC8yIFtSRkM3NTQwXSB1c2VzIEhQQUNLIFtSRkM3NTQx XSBmb3IgaGVhZGVyIGNvbXByZXNzaW9uLg0KDQogICBIb3dldmVyLCBIUEFDSyByZWxpZXMgb24g dGhlIGluLW9yZGVyIG1lc3NhZ2UtYmFzZWQgc2VtYW50aWNzIG9mIHRoZQ0KDQogICBIVFRQLzIg ZnJhbWluZyBsYXllciBpbiBvcmRlciB0byBmdW5jdGlvbi4gIE1lc3NhZ2VzIGNhbiBvbmx5IGJl DQoNCiAgIHN1Y2Nlc3NmdWxseSBkZWNvZGVkIGlmIHByb2Nlc3NlZCBieSB0aGUgZGVjb2RlciBp biB0aGUgc2FtZSBvcmRlciBhcw0KDQogICBnZW5lcmF0ZWQgYnkgdGhlIGVuY29kZXIuICBUaGlz IGRyYWZ0IHJlZmluZXMgSFBBQ0sgdG8gbG9vc2VuIHRoZQ0KDQogICBvcmRlcmluZyByZXF1aXJl bWVudHMgZm9yIHVzZSBvdmVyIFFVSUMgW0ktRC5pZXRmLXF1aWMtdHJhbnNwb3J0XS4NCg0KDQoN Cg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_BN6PR03MB27086B368C567F3C950E67D1877F0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTU5MzY2MTQ4Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODgwMzczNTM4IDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+V2l0aCB0aGUgcmVjZW50IHB1YmxpY2F0aW9uIG9mIHRoZSBXRyAtMDEgZHJhZnRz LCBJJ3ZlIHVwZGF0ZWQgbXkgUVBBQ0sgZHJhZnQgdG8gLTAxIGFzIHdlbGwuJm5ic3A7IE5vdGFi bGUgbm9uLWVkaXRvcmlhbCBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UmVhbGl6ZWQgd2UgZGlk buKAmXQgbmVlZCB0aGUgYWJpbGl0eSBmb3IgdGhlIGVuY29kZXIgdG8gZGVjbGFyZSBhIHRhYmxl IHNpemUgaWYgdGhlIGVuY29kZXIgaXMgZXhwbGljaXRseSBtYW5hZ2luZyB0aGUgdGFibGUuJm5i c3A7IFRoZXJlZm9yZSwgSSBjYW4gc3RlYWwgdGhlIOKAnHNpemUgY2hhbmdl4oCdIGluc3RydWN0 aW9uIHJhdGhlcg0KIHRoYW4gdGhlIOKAnG5ldmVyLWluZGV4ZWTigJ0gaW5zdHJ1Y3Rpb24uJm5i c3A7IFJlc29sdmVzIG9uZSBvZiB0aGUgbWFqb3IgZHJhd2JhY2tzLjxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+UmVtb3ZlZCB0aGUgcHJvcG9zZWQgSFRUUC9RVUlDIG1hcHBpbmcsIHNp bmNlIHRoYXTigJlzIG5vdyBsYXJnZWx5IGluY29ycG9yYXRlZCBpbnRvIHRoZSBXRyBkb2N1bWVu dC4mbmJzcDsgUmVwbGFjZWQgd2l0aCBhIG11Y2ggc2hvcnRlciBzZWN0aW9uIG9uIGhvdyB0byBz bG90IFFQQUNLIGludG8gaHEtMDEuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5DbGFy aWZpZWQgaG93IGNoYW5nZXMgdG8gbWF4aW11bSB0YWJsZSBzaXplIGR1cmluZyBhIGxpdmUgY29u bmVjdGlvbiBhcmUgaGFuZGxlZCwgZXNwZWNpYWxseSBpbiBsaWdodCBvZiB0aGUgc2V0dGluZ3Mt c3luY2hyb25pemF0aW9uIHRleHQgdGhhdOKAmXMgYmVlbiBhZGRlZCB0byBocS0wMS48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIDxicj4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTcgNDowMSBQ TTxicj4NClRvOiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZn dDs8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJpc2hv cC1xdWljLWh0dHAtYW5kLXFwYWNrLTAxLnR4dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2stMDEudHh0PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IE1pa2UgQmlzaG9wIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2s8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlzaW9uOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAwMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGl0bGU6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEhlYWRlciBDb21wcmVzc2lvbiBmb3IgSFRUUC9RVUlDPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Eb2N1bWVudCBkYXRlOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAyMDE3LTAxLTE3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5QYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlVSTDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAxLnR4dCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAxLnR4dDwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXM6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpc2hvcC1xdWljLWh0dHAt YW5kLXFwYWNrLyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmlzaG9wLXF1 aWMtaHR0cC1hbmQtcXBhY2svPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmlzaG9wLXF1aWMt aHR0cC1hbmQtcXBhY2stMDEiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3At cXVpYy1odHRwLWFuZC1xcGFjay0wMTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2stMDEiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay0w MTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEhUVFAvMiBb UkZDNzU0MF0gdXNlcyBIUEFDSyBbUkZDNzU0MV0gZm9yIGhlYWRlciBjb21wcmVzc2lvbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBIb3dldmVy LCBIUEFDSyByZWxpZXMgb24gdGhlIGluLW9yZGVyIG1lc3NhZ2UtYmFzZWQgc2VtYW50aWNzIG9m IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IEhUVFAvMiBmcmFtaW5nIGxheWVyIGluIG9yZGVyIHRvIGZ1bmN0aW9uLiZuYnNwOyBNZXNzYWdl cyBjYW4gb25seSBiZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7IHN1Y2Nlc3NmdWxseSBkZWNvZGVkIGlmIHByb2Nlc3NlZCBieSB0aGUgZGVjb2Rl ciBpbiB0aGUgc2FtZSBvcmRlciBhczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IGdlbmVyYXRlZCBieSB0aGUgZW5jb2Rlci4mbmJzcDsgVGhpcyBk cmFmdCByZWZpbmVzIEhQQUNLIHRvIGxvb3NlbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBvcmRlcmluZyByZXF1aXJlbWVudHMgZm9yIHVz ZSBvdmVyIFFVSUMgW0ktRC5pZXRmLXF1aWMtdHJhbnNwb3J0XS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN6PR03MB27086B368C567F3C950E67D1877F0BN6PR03MB2708namp_-- From nobody Wed Jan 18 02:05:28 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 E5BA81289C4; Wed, 18 Jan 2017 02:05:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: quic - Update to a Meeting Session Request for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148473392690.21322.2591445041110974493.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 02:05:26 -0800 Archived-At: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 10:05:27 -0000 An update to a meeting session request has just been submitted by Lars Eggert, a Chair of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 250 Conflicts to Avoid: First Priority: irtfopen artarea taps mptcp tcpinc tcpm iccrg tsvwg maprg dispatch httpbis tls saag tsvarea Second Priority: rtcweb webpush acme t2trg Special Requests: --------------------------------------------------------- From nobody Wed Jan 18 19:08: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 5D237126579 for ; Wed, 18 Jan 2017 19:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D84GIkZWLIjS for ; Wed, 18 Jan 2017 19:08:22 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CFC12940F for ; Wed, 18 Jan 2017 19:08:22 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7B84D22E257; Wed, 18 Jan 2017 22:08:18 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Remote participation in next week's Inteirm meeting Date: Thu, 19 Jan 2017 14:08:13 +1100 Message-Id: <209B1FF1-B0C3-4C13-8FF3-4B4106F38840@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Lars Eggert X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Mark Nottingham List-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, 19 Jan 2017 03:08:25 -0000 If you registered to attend remotely, you should have received an = invitation from WebEx by now. If you haven't, please contact me and I'll forward you the details. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 18 19:29: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 57F1B1294AE for ; Wed, 18 Jan 2017 19:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLbxr4uKXoWS for ; Wed, 18 Jan 2017 19:29:21 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B78212949F for ; Wed, 18 Jan 2017 19:29:21 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id l7so46425290qtd.1 for ; Wed, 18 Jan 2017 19:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=st+N5FBbO3KUUPnSJFxX3gPpAEFDACwJvBDO8ESnt/0=; b=tK7h9rHPySgk01WIH3aWiQkdK5WuAwf1nSKb5QML0by0e2QZ40p6vQ0jHC+f3OBuMQ iSpjGeLbcINudRVS1GgaOaBCxCztCfoTQ/CueypW+4N6yl/NslX09bBI6pKXjQwiWZnp KaISoCB+oyA/M4cTqO66JhcaRXu1TZVcDGljFDDdQdwJPduw8YDm3PTMFkaMzaU3WBmz bNPV1Spto4AibwFVQvUSpvgtSimqKwQX/L/OFBTTbGaBctIMv80Vw5AP6s5LosR0SMsZ p0B3d1LhoRVE+lUpYbMtFU38d6eTQPR70dEQJUfd1sl58XoVZ6MCX2q6xH9DZWZsgY7h RS5Q== 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=st+N5FBbO3KUUPnSJFxX3gPpAEFDACwJvBDO8ESnt/0=; b=ipLLEOmX5XmWcqbiJUT4OgbPWPOCT1kArz6z1DPjvnFDwFN/Ojtgv0o1HF3HFs+kAi CQyoSOhAoZ8zz7ma6VR7Qyx8gWo+Y+q/Wpe88vt7iMa6myeOhfl2hGOzTDqOfz6pcCDw hZBUKwjAdiq+b/aEm2oTuyoYOCiOtkBAacqenFkD3QjkSOqdexMXCPqcWff4f91Zii9R BFhh82YlD+F5EQE+Dh2LtLjBHo5gAPdQfbgwQgO4BSRW01SEnh7be32UXEQI+9Up6D1B TKpmif36JULRAsbXetwyv71SCw0WexXlViEbsqw50WyZMQXIcrXa9w+/BF5DTDjnaCqP n8mw== X-Gm-Message-State: AIkVDXJOBw3ETus4ACxvDz04jnZBo+h36v17sTd3+sUkLbitYpHHdqk+BQTJrtJXUphJ5KMhoOfIFndzrOHt4w== X-Received: by 10.200.53.247 with SMTP id l52mr6027624qtb.144.1484796560444; Wed, 18 Jan 2017 19:29:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 18 Jan 2017 19:29:19 -0800 (PST) In-Reply-To: References: <148469766991.32074.16605318271142170510.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 19 Jan 2017 16:29:19 +1300 Message-ID: Subject: Re: FW: New Version Notification for draft-bishop-quic-http-and-qpack-01.txt To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:29:23 -0000 Thanks for putting this together Mike. I think that this is the right direction to go for QUIC. It is marginally more complex than HPACK, but only to the extent necessary (modulo one issue below). I notice you mention "incremental indexing" in a few places still, that probably needs fixing. For QPACK-ACK, presumably this is sent on stream 3?2? I think that you should invert the meaning and only include bits for entries that still have a value (at the time of sending). This allows a sender to verify that deletion has happened, but also allows this to be a cumulative message rather than an incremental one. It might also allow for a smaller message if a sender packs all their more stable values at the low end of the table - deletes at the end of table don't need to be signaled at all. Editorially, I think that this is the right way to present this now for the working group, but ultimately I think that I would prefer to see a more standalone document. If that means replicating text from HPACK, I think that would be better than having gaps. It would also give us the chance to make some of those long-outstanding changes we promised to the static table; maybe even informed by new and more relevant data from h2. An issue that needs some thought: a reset stream might include a reference to an index entry. However that reference won't be repaired in the event of loss after a reset. We need a strategy for dealing with that and I can't think of one offhand. I found the description of the states a little confusing. In particular, the mixing of encoder and decoder state descriptions was hard to follow. Separating those would be better, I think. The encoder only needs to know what entries exist, what entries are dead but consuming space, and what entries are free. The decoder needs more precise accounting about the number of uses and when the uses hit a delete threshold. The actual algorithm can be quite elegant: At the decoder, counters for use_count and delete_count, plus the slots for name and value, are sufficient. I think that's all you need aside from maybe an index number slot, so it's probably OK not to change the 32 octet-per-entry allowance from HPACK, even though you need to add these counters. A value of 0 for use_count indicates that the field is unused and can be allocated to safely. A value of 0 for delete_count indicates that a delete hasn't been requested. When an insert or reference happens (including the first insert): ++use_count; when a delete is requested, set delete_count. In both cases, also add a check for delete_count =3D=3D use_count, in which case you free the entry. The encoder doesn't need to use the delete_count, but it does need to remember that the slot existed previously - and how big it was - so that it doesn't reuse it before the decoder confirms that it's OK to do so. Switching delete_count for a size counter would do for that purpose. There's nothing preventing an encoder from using high index numbers. That could be quite inefficient and potentially dangerous for a decoder that wasn't prepared for it. Do we need a cap on the index value just to prevent silliness? (table_size /32) would be the absolute largest sensible value. On 18 January 2017 at 13:07, Mike Bishop wro= te: > With the recent publication of the WG -01 drafts, I've updated my QPACK > draft to -01 as well. Notable non-editorial changes: > > Realized we didn=E2=80=99t need the ability for the encoder to declare a = table size > if the encoder is explicitly managing the table. Therefore, I can steal = the > =E2=80=9Csize change=E2=80=9D instruction rather than the =E2=80=9Cnever-= indexed=E2=80=9D instruction. > Resolves one of the major drawbacks. > Removed the proposed HTTP/QUIC mapping, since that=E2=80=99s now largely > incorporated into the WG document. Replaced with a much shorter section = on > how to slot QPACK into hq-01. > Clarified how changes to maximum table size during a live connection are > handled, especially in light of the settings-synchronization text that=E2= =80=99s > been added to hq-01. > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, January 17, 2017 4:01 PM > To: Mike Bishop > Subject: New Version Notification for > draft-bishop-quic-http-and-qpack-01.txt > > > > > > A new version of I-D, draft-bishop-quic-http-and-qpack-01.txt > > has been successfully submitted by Mike Bishop and posted to the IETF > repository. > > > > Name: draft-bishop-quic-http-and-qpack > > Revision: 01 > > Title: Header Compression for HTTP/QUIC > > Document date: 2017-01-17 > > Group: Individual Submission > > Pages: 10 > > URL: > https://www.ietf.org/internet-drafts/draft-bishop-quic-http-and-qpack-01.= txt > > Status: > https://datatracker.ietf.org/doc/draft-bishop-quic-http-and-qpack/ > > Htmlized: > https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-bishop-quic-http-and-qpack-01 > > > > Abstract: > > HTTP/2 [RFC7540] uses HPACK [RFC7541] for header compression. > > However, HPACK relies on the in-order message-based semantics of the > > HTTP/2 framing layer in order to function. Messages can only be > > successfully decoded if processed by the decoder in the same order as > > generated by the encoder. This draft refines HPACK to loosen the > > ordering requirements for use over QUIC [I-D.ietf-quic-transport]. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > From nobody Wed Jan 18 22:32: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 5DEBF12949A for ; Wed, 18 Jan 2017 22:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG71JZasPqm7 for ; Wed, 18 Jan 2017 22:31:59 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0119.outbound.protection.outlook.com [104.47.32.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7131200A0 for ; Wed, 18 Jan 2017 22:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MsjoelCxh4/RGazl6hIG6ucwk4i/VjyW+S1pypEiqN0=; b=Pq1xrSKFxFhCR75hH9JS2ptdQUMbvqDpbcBYBQXFxrvEz0xZGXvYy513/Yv9hnCxj0apjAmlVIGlvdJ2KDHDr/CdUWBXWTHTm65RVlYx1UIfK29Jizxp4olmh3Drcqf13FWlt5Nf8nIQ2gNlHOChLb/876L04dxu/99y3Dzoof0= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 19 Jan 2017 06:31:57 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0845.013; Thu, 19 Jan 2017 06:31:57 +0000 From: Mike Bishop To: Martin Thomson Subject: RE: FW: New Version Notification for draft-bishop-quic-http-and-qpack-01.txt Thread-Topic: FW: New Version Notification for draft-bishop-quic-http-and-qpack-01.txt Thread-Index: AQHScR38qy/GgUo6fUWbv/Z48maJxqE9WlhwgAHL24CAAC4k0A== Date: Thu, 19 Jan 2017 06:31:56 +0000 Message-ID: References: <148469766991.32074.16605318271142170510.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:29b3:c810:e244:75ae] x-ms-office365-filtering-correlation-id: 86785cfb-9bf3-42f9-d66b-08d44034dde8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:aSAwHY7abqIWdPuGwoVZxihsHfYVtyWC4HllX92LRo4qLhkCFmB5jzbHy4kXz3Fz/G9N6HZxGbZakAvr4/t0QIWJgRTWl853rykKGrZd+JjN6W5KuWRZlWfKKBAlxDdYP/w+paPxsuwTA6ugtDK2a16u06XV7bU9THwiCFeN4ElsXMR4XESyphVKh+Z2YicqUwScgTBBPwzEnhHPmdTHMs1W5BxtVw26QVGq5AVsg2Azz9cVjKq/JppZF4cdUoa0liPhQQ6FkCK0AV8oxkF0hWwZ2Q9bzJDYPNC3dGHeMk6O3Z5aohlAHquoKDk2kHWPdw3VA5yVaaByYw3U97TUvZRjzFhaDn9//ciL2dTbOYUEYGSu3XVAfM5zusfOjq9JJGzDgIHlLF+nI7RjA0vW6BnKGJkrv/zovqQ+HC4HaQ9rfMw1/inOelJoEzkpR67lHDHpmEiynYSVWbl5CbkdNOuRBckQKawlGqA7jE43I8U= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6042181)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(57704003)(199003)(13464003)(24454002)(377424004)(51444003)(377454003)(5660300001)(101416001)(790700001)(102836003)(6116002)(50986999)(33656002)(7906003)(7736002)(54356999)(74316002)(76176999)(8990500004)(110136003)(5005710100001)(68736007)(10090500001)(10290500002)(10710500007)(105586002)(97736004)(2906002)(106116001)(106356001)(2420400007)(3660700001)(122556002)(15650500001)(4326007)(7696004)(3280700002)(229853002)(2950100002)(6916009)(7110500001)(92566002)(8936002)(189998001)(2900100001)(86362001)(230783001)(8676002)(55016002)(99286003)(81156014)(77096006)(81166006)(39060400001)(38730400001)(9686003)(236005)(606005)(6436002)(54896002)(6506006)(6306002)(86612001)(53936002)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270853D7DBA48E58602BC32B877E0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 06:31:56.8110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 06:32:03 -0000 --_000_BN6PR03MB270853D7DBA48E58602BC32B877E0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBRUEFDSy1BQ0sgaXMgb24gdGhlIGNvbm5lY3Rpb24gY29udHJvbCBzdHJlYW0sIHdoaWNo IGlzIHN0cmVhbSAzOyB0aGF0J3MgbWVudGlvbmVkIGJ5IG5hbWUsIGJ1dCBub3QgYnkgc3RyZWFt IG51bWJlci4NCg0KDQoNCkluIGFuIHVucHVibGlzaGVkIHByZXZpb3VzIHZlcnNpb24sIHRoZSBB Q0sgd2FzIGEgYml0bWFwIG9mIGFsbCBzbG90cyBpbiB0aGUgdGFibGUsIGluZGljYXRpbmcgb2Nj dXBpZWQgb3Igbm90LCBhcyB5b3Ugc3VnZ2VzdC4gIFdoYXQgY2F1c2VkIGl0IHRvIGNoYW5nZSBp cyB0aGlzIHVubGlrZWx5LWJ1dC1wb3NzaWJsZSBzY2VuYXJpbzoNCg0KwrcgICAgICAgIEVuY29k ZXIgaW5zZXJ0cyB0byBzbG90IEENCg0KbyAgIFRoaXMgZnJhbWUgaXMgZGVsYXllZA0KDQrCtyAg ICAgICAgRW5jb2RlciBkZWxldGVzIHNsb3QgQQ0KDQpvICAgVGhpcyBmcmFtZSBpcyBhbHNvIGRl bGF5ZWQNCg0KwrcgICAgICAgIEVuY29kZXIgcmVjZWl2ZXMgYSBRUEFDSy1BQ0sgaW5kaWNhdGlu ZyB0aGF0IEEgaXMgZW1wdHkNCg0KDQoNCkF0IHRoaXMgcG9pbnQsIHdpdGhvdXQgcXVlcnlpbmcg dGhlIHRyYW5zcG9ydCB0byBzZWUgd2hpY2ggZnJhbWVzIGhhdmUvaGF2ZW7igJl0IGJlZW4gYWNr bm93bGVkZ2VkLCB0aGUgZW5jb2RlciBkb2VzbuKAmXQga25vdyB3aGV0aGVyIGRlbGV0ZShBKSBo YXMgY29tcGxldGUgc3VjY2Vzc2Z1bGx5LCBvciBpbnNlcnQoQSkgaGFzbuKAmXQgaGFwcGVuZWQg eWV0LiAgSW4gb3JkZXIgdG8gbWl0aWdhdGUgdGhhdCwgdGhlIGVuY29kZXIgb3JpZ2luYWxseSB3 YXNu4oCZdCBhbGxvd2VkIHRvIHNlbmQgZGVsZXRlKEEpIHVudGlsIGl0IGhhZCBzZWVuIGEgUVBB Q0stQUNLIGZyYW1lIGluZGljYXRpbmcgdGhlIHNsb3QgYXMgb2NjdXBpZWQuDQoNCg0KDQpBbHRl cm5hdGl2ZWx5LCBzaW5jZSB5b3Uga25vdyB0aGF0IHN0cmVhbSAzIGlzIGFsd2F5cyBpbiBvcmRl ciwgeW91IGNvdWxkIHNheSB0aGF0IHlvdSBjYW7igJl0IGNvbnNpZGVyIHRoZSBkZWxldGUgdG8g aGF2ZSBvY2N1cnJlZCB1bnRpbCB5b3UgaGF2ZSBzZWVuIHRoZSBzbG90IGZpbGxlZCBpbiBhdCBs ZWFzdCBvbmUgUVBBQ0stQUNLLCB0aGVuIGVtcHR5IGluIGF0IGxlYXN0IG9uZSBRUEFDSy1BQ0su ICBCdXQgdGhlbiBkZWNvZGVycyBoYXZlIHRvIG1ha2Ugc3VyZSBub3QgdG8gc2VuZCBhIFFQQUNL LUFDSyBmcmFtZSB0aGF0IHJlZmxlY3RzIGJvdGggYW4gYWRkIGFuZCBhIGRlbGV0ZSB0byB0aGUg c2FtZSBzbG90LiAgVGhhdCBzZWVtcyBsaWtlIGl0IGdldHMgaW50byBtb3JlIHJlY29yZGtlZXBp bmcgdGhhbiBJIHdhbnRlZCwgYnV0IG1pZ2h0IGJlIGEgdmlhYmxlIHNvbHV0aW9uOiAgS2VlcCBh IGxpc3Qgb2YgYWxsIHNsb3RzIHdpdGggY2hhbmdlcyBzaW5jZSB5b3VyIGxhc3QgUVBBQ0stQUNL OyBpZiB5b3UgZW5jb3VudGVyIGEgZHVwbGljYXRlIHlvdSBNVVNUIGVtaXQgdGhlIFFBIGZyYW1l IGFuZCBtYWtlIHRoZSBkdXBsaWNhdGUgdGhlIGZpcnN0IGNoYW5nZSBhY2N1bXVsYXRpbmcgdG93 YXJkIHlvdXIgbmV4dCBRUEFDSy1BQ0suDQoNCg0KDQpCeSBzd2l0Y2hpbmcgdG8gYW4gaW5jcmVt ZW50YWwgUVBBQ0stQUNLLCB0aGUgc3RhdGUgbWFjaGluZSBiZWNvbWVzIHJlYWxseSBzaW1wbGUg 4oCTIGVuY29kZXJzIGp1c3QgaW5zZXJ0IGFuZCB0cnVzdCB0aGF0IHRoZSBkZWxldGUgY291bnRl ciB3aWxsIGNvdmVyIGl0LiAgRGVjb2RlcnMgY2FuIGFjY3VtdWxhdGUgYXMgbXVjaCBhcyB0aGV5 IHdhbnQgaW50byBhIHNpbmdsZSBRUEFDSy1BQ0sgZnJhbWUsIGJlY2F1c2UgdGhlIHNlbmRlciBp c27igJl0IGFsbG93ZWQgdG8gaXNzdWUgaW5zdHJ1Y3Rpb25zIHRoYXQgd291bGQgZ2VuZXJhdGUg ZHVwbGljYXRlcy4NCg0KDQoNClRoZSBmYWN0IHRoYXQgaW5zZXJ0cyBtaWdodCBoYXZlIGJlZW4g bG9zdCBkdWUgdG8gYSByZXNldCBpcyBhIHdyaW5rbGUgSSBoYWRu4oCZdCBjb25zaWRlcmVkLCBh bmQgbm90IG9uZSBJIGhhdmUgYSByZWFkeSBzb2x1dGlvbiB0by4gVGhhdOKAmXMgYSBzZXJpb3Vz IGlzc3VlIGFwcGxpY2FibGUgdG8gSFBBQ0sgaW4gdGhlIGN1cnJlbnQgZHJhZnQgLTAxIGFzIHdl bGwuICBXZeKAmWxsIGhhdmUgdG8gdGhpbmsgYWJvdXQgdGhhdCBvbmUg4oCTIHRoZXJlIGFyZSBh IGxvdCBvZiBicmlnaHQgcGVvcGxlIGhlcmUsIHNvIEnigJltIHN1cmUgc29tZW9uZSB3aWxsIGNv bWUgdXAgd2l0aCBzb21ldGhpbmcuICBJZiBub3RoaW5nIGVsc2UsIGdpdmVuIHRoYXQgaGVhZGVy cyBhcmUgdXN1YWxseSBzbWFsbCwgd2UgY291bGQgc2F5IHRoYXQgb25seSB0aGUgZGF0YSBzdHJl YW1zIGdldCBSU1QsIG5ldmVyIHRoZSBoZWFkZXIgc3RyZWFtcy4NCg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxNyA3OjI5IFBN DQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzogSUVU RiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAxLnR4dA0K DQoNCg0KVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIgTWlrZS4NCg0KDQoNCkkgdGhp bmsgdGhhdCB0aGlzIGlzIHRoZSByaWdodCBkaXJlY3Rpb24gdG8gZ28gZm9yIFFVSUMuICBJdCBp cyBtYXJnaW5hbGx5IG1vcmUgY29tcGxleCB0aGFuIEhQQUNLLCBidXQgb25seSB0byB0aGUgZXh0 ZW50IG5lY2Vzc2FyeSAobW9kdWxvIG9uZSBpc3N1ZSBiZWxvdykuDQoNCg0KDQpJIG5vdGljZSB5 b3UgbWVudGlvbiAiaW5jcmVtZW50YWwgaW5kZXhpbmciIGluIGEgZmV3IHBsYWNlcyBzdGlsbCwg dGhhdCBwcm9iYWJseSBuZWVkcyBmaXhpbmcuDQoNCg0KDQpGb3IgUVBBQ0stQUNLLCBwcmVzdW1h Ymx5IHRoaXMgaXMgc2VudCBvbiBzdHJlYW0gMz8yPyAgSSB0aGluayB0aGF0IHlvdSBzaG91bGQg aW52ZXJ0IHRoZSBtZWFuaW5nIGFuZCBvbmx5IGluY2x1ZGUgYml0cyBmb3IgZW50cmllcyB0aGF0 IHN0aWxsIGhhdmUgYSB2YWx1ZSAoYXQgdGhlIHRpbWUgb2Ygc2VuZGluZykuICBUaGlzIGFsbG93 cyBhIHNlbmRlciB0byB2ZXJpZnkgdGhhdCBkZWxldGlvbiBoYXMgaGFwcGVuZWQsIGJ1dCBhbHNv IGFsbG93cyB0aGlzIHRvIGJlIGEgY3VtdWxhdGl2ZSBtZXNzYWdlIHJhdGhlciB0aGFuIGFuIGlu Y3JlbWVudGFsIG9uZS4gIEl0IG1pZ2h0IGFsc28gYWxsb3cgZm9yIGEgc21hbGxlciBtZXNzYWdl IGlmIGEgc2VuZGVyIHBhY2tzIGFsbCB0aGVpciBtb3JlIHN0YWJsZSB2YWx1ZXMgYXQgdGhlIGxv dyBlbmQgb2YgdGhlIHRhYmxlIC0gZGVsZXRlcyBhdCB0aGUgZW5kIG9mIHRhYmxlIGRvbid0IG5l ZWQgdG8gYmUgc2lnbmFsZWQgYXQgYWxsLg0KDQoNCg0KRWRpdG9yaWFsbHksIEkgdGhpbmsgdGhh dCB0aGlzIGlzIHRoZSByaWdodCB3YXkgdG8gcHJlc2VudCB0aGlzIG5vdyBmb3IgdGhlIHdvcmtp bmcgZ3JvdXAsIGJ1dCB1bHRpbWF0ZWx5IEkgdGhpbmsgdGhhdCBJIHdvdWxkIHByZWZlciB0byBz ZWUgYSBtb3JlIHN0YW5kYWxvbmUgZG9jdW1lbnQuICBJZiB0aGF0IG1lYW5zIHJlcGxpY2F0aW5n IHRleHQgZnJvbSBIUEFDSywgSSB0aGluayB0aGF0IHdvdWxkIGJlIGJldHRlciB0aGFuIGhhdmlu ZyBnYXBzLiAgSXQgd291bGQgYWxzbyBnaXZlIHVzIHRoZSBjaGFuY2UgdG8gbWFrZSBzb21lIG9m IHRob3NlIGxvbmctb3V0c3RhbmRpbmcgY2hhbmdlcyB3ZSBwcm9taXNlZCB0byB0aGUgc3RhdGlj IHRhYmxlOyBtYXliZSBldmVuIGluZm9ybWVkIGJ5IG5ldyBhbmQgbW9yZSByZWxldmFudCBkYXRh IGZyb20gaDIuDQoNCg0KDQpBbiBpc3N1ZSB0aGF0IG5lZWRzIHNvbWUgdGhvdWdodDogYSByZXNl dCBzdHJlYW0gbWlnaHQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBhbiBpbmRleCBlbnRyeS4gIEhv d2V2ZXIgdGhhdCByZWZlcmVuY2Ugd29uJ3QgYmUgcmVwYWlyZWQgaW4gdGhlIGV2ZW50IG9mIGxv c3MgYWZ0ZXIgYSByZXNldC4gIFdlIG5lZWQgYSBzdHJhdGVneSBmb3IgZGVhbGluZyB3aXRoIHRo YXQgYW5kIEkgY2FuJ3QgdGhpbmsgb2Ygb25lIG9mZmhhbmQuDQoNCg0KDQpJIGZvdW5kIHRoZSBk ZXNjcmlwdGlvbiBvZiB0aGUgc3RhdGVzIGEgbGl0dGxlIGNvbmZ1c2luZy4gIEluIHBhcnRpY3Vs YXIsIHRoZSBtaXhpbmcgb2YgZW5jb2RlciBhbmQgZGVjb2RlciBzdGF0ZSBkZXNjcmlwdGlvbnMg d2FzIGhhcmQgdG8gZm9sbG93LiAgU2VwYXJhdGluZyB0aG9zZSB3b3VsZCBiZSBiZXR0ZXIsIEkg dGhpbmsuICBUaGUgZW5jb2RlciBvbmx5IG5lZWRzIHRvIGtub3cgd2hhdCBlbnRyaWVzIGV4aXN0 LCB3aGF0IGVudHJpZXMgYXJlIGRlYWQgYnV0IGNvbnN1bWluZyBzcGFjZSwgYW5kIHdoYXQgZW50 cmllcyBhcmUgZnJlZS4gIFRoZSBkZWNvZGVyIG5lZWRzIG1vcmUgcHJlY2lzZSBhY2NvdW50aW5n IGFib3V0IHRoZSBudW1iZXIgb2YgdXNlcyBhbmQgd2hlbiB0aGUgdXNlcyBoaXQgYSBkZWxldGUg dGhyZXNob2xkLg0KDQoNCg0KVGhlIGFjdHVhbCBhbGdvcml0aG0gY2FuIGJlIHF1aXRlIGVsZWdh bnQ6IEF0IHRoZSBkZWNvZGVyLCBjb3VudGVycyBmb3IgdXNlX2NvdW50IGFuZCBkZWxldGVfY291 bnQsIHBsdXMgdGhlIHNsb3RzIGZvciBuYW1lIGFuZCB2YWx1ZSwgYXJlIHN1ZmZpY2llbnQuICBJ IHRoaW5rIHRoYXQncyBhbGwgeW91IG5lZWQgYXNpZGUgZnJvbSBtYXliZSBhbiBpbmRleCBudW1i ZXIgc2xvdCwgc28gaXQncyBwcm9iYWJseSBPSyBub3QgdG8gY2hhbmdlIHRoZSAzMiBvY3RldC1w ZXItZW50cnkgYWxsb3dhbmNlIGZyb20gSFBBQ0ssIGV2ZW4gdGhvdWdoIHlvdSBuZWVkIHRvIGFk ZCB0aGVzZSBjb3VudGVycy4NCg0KDQoNCkEgdmFsdWUgb2YgMCBmb3IgdXNlX2NvdW50IGluZGlj YXRlcyB0aGF0IHRoZSBmaWVsZCBpcyB1bnVzZWQgYW5kIGNhbiBiZSBhbGxvY2F0ZWQgdG8gc2Fm ZWx5LiAgQSB2YWx1ZSBvZiAwIGZvciBkZWxldGVfY291bnQgaW5kaWNhdGVzIHRoYXQgYSBkZWxl dGUgaGFzbid0IGJlZW4gcmVxdWVzdGVkLiAgV2hlbiBhbiBpbnNlcnQgb3IgcmVmZXJlbmNlIGhh cHBlbnMgKGluY2x1ZGluZyB0aGUgZmlyc3QgaW5zZXJ0KTogKyt1c2VfY291bnQ7IHdoZW4gYSBk ZWxldGUgaXMgcmVxdWVzdGVkLCBzZXQgZGVsZXRlX2NvdW50LiAgSW4gYm90aCBjYXNlcywgYWxz byBhZGQgYSBjaGVjayBmb3IgZGVsZXRlX2NvdW50ID09IHVzZV9jb3VudCwgaW4gd2hpY2ggY2Fz ZSB5b3UgZnJlZSB0aGUgZW50cnkuDQoNCg0KDQpUaGUgZW5jb2RlciBkb2Vzbid0IG5lZWQgdG8g dXNlIHRoZSBkZWxldGVfY291bnQsIGJ1dCBpdCBkb2VzIG5lZWQgdG8gcmVtZW1iZXIgdGhhdCB0 aGUgc2xvdCBleGlzdGVkIHByZXZpb3VzbHkgLSBhbmQgaG93IGJpZyBpdCB3YXMgLSBzbyB0aGF0 IGl0IGRvZXNuJ3QgcmV1c2UgaXQgYmVmb3JlIHRoZSBkZWNvZGVyIGNvbmZpcm1zIHRoYXQgaXQn cyBPSyB0byBkbyBzby4gIFN3aXRjaGluZyBkZWxldGVfY291bnQgZm9yIGEgc2l6ZSBjb3VudGVy IHdvdWxkIGRvIGZvciB0aGF0IHB1cnBvc2UuDQoNCg0KDQpUaGVyZSdzIG5vdGhpbmcgcHJldmVu dGluZyBhbiBlbmNvZGVyIGZyb20gdXNpbmcgaGlnaCBpbmRleCBudW1iZXJzLg0KDQpUaGF0IGNv dWxkIGJlIHF1aXRlIGluZWZmaWNpZW50IGFuZCBwb3RlbnRpYWxseSBkYW5nZXJvdXMgZm9yIGEg ZGVjb2RlciB0aGF0IHdhc24ndCBwcmVwYXJlZCBmb3IgaXQuICBEbyB3ZSBuZWVkIGEgY2FwIG9u IHRoZSBpbmRleCB2YWx1ZSBqdXN0IHRvIHByZXZlbnQgc2lsbGluZXNzPyAgKHRhYmxlX3NpemUg LzMyKSB3b3VsZCBiZSB0aGUgYWJzb2x1dGUgbGFyZ2VzdCBzZW5zaWJsZSB2YWx1ZS4NCg0KDQoN Ck9uIDE4IEphbnVhcnkgMjAxNyBhdCAxMzowNywgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCg0KPiBXaXRoIHRoZSByZWNlbnQgcHVibGljYXRpb24gb2YgdGhlIFdHIC0wMSBkcmFmdHMs IEkndmUgdXBkYXRlZCBteQ0KDQo+IFFQQUNLIGRyYWZ0IHRvIC0wMSBhcyB3ZWxsLiAgTm90YWJs ZSBub24tZWRpdG9yaWFsIGNoYW5nZXM6DQoNCj4NCg0KPiBSZWFsaXplZCB3ZSBkaWRu4oCZdCBu ZWVkIHRoZSBhYmlsaXR5IGZvciB0aGUgZW5jb2RlciB0byBkZWNsYXJlIGEgdGFibGUNCg0KPiBz aXplIGlmIHRoZSBlbmNvZGVyIGlzIGV4cGxpY2l0bHkgbWFuYWdpbmcgdGhlIHRhYmxlLiAgVGhl cmVmb3JlLCBJDQoNCj4gY2FuIHN0ZWFsIHRoZSDigJxzaXplIGNoYW5nZeKAnSBpbnN0cnVjdGlv biByYXRoZXIgdGhhbiB0aGUg4oCcbmV2ZXItaW5kZXhlZOKAnSBpbnN0cnVjdGlvbi4NCg0KPiBS ZXNvbHZlcyBvbmUgb2YgdGhlIG1ham9yIGRyYXdiYWNrcy4NCg0KPiBSZW1vdmVkIHRoZSBwcm9w b3NlZCBIVFRQL1FVSUMgbWFwcGluZywgc2luY2UgdGhhdOKAmXMgbm93IGxhcmdlbHkNCg0KPiBp bmNvcnBvcmF0ZWQgaW50byB0aGUgV0cgZG9jdW1lbnQuICBSZXBsYWNlZCB3aXRoIGEgbXVjaCBz aG9ydGVyDQoNCj4gc2VjdGlvbiBvbiBob3cgdG8gc2xvdCBRUEFDSyBpbnRvIGhxLTAxLg0KDQo+ IENsYXJpZmllZCBob3cgY2hhbmdlcyB0byBtYXhpbXVtIHRhYmxlIHNpemUgZHVyaW5nIGEgbGl2 ZSBjb25uZWN0aW9uDQoNCj4gYXJlIGhhbmRsZWQsIGVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgdGhl IHNldHRpbmdzLXN5bmNocm9uaXphdGlvbiB0ZXh0DQoNCj4gdGhhdOKAmXMgYmVlbiBhZGRlZCB0 byBocS0wMS4NCg0KPg0KDQo+DQoNCj4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K DQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCg0KPiBTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDE3LCAyMDE3IDQ6MDEgUE0NCg0KPiBUbzogTWlrZSBCaXNob3AgPE1p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29m dC5jb20+Pg0KDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCg0KPiBk cmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay0wMS50eHQNCg0KPg0KDQo+DQoNCj4NCg0K Pg0KDQo+DQoNCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAt YW5kLXFwYWNrLTAxLnR4dA0KDQo+DQoNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBNaWtlIEJpc2hvcCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQoNCj4gcmVwb3NpdG9yeS4N Cg0KPg0KDQo+DQoNCj4NCg0KPiBOYW1lOiAgICAgICAgICAgICAgICAgIGRyYWZ0LWJpc2hvcC1x dWljLWh0dHAtYW5kLXFwYWNrDQoNCj4NCg0KPiBSZXZpc2lvbjogICAgICAgICAgICAgIDAxDQoN Cj4NCg0KPiBUaXRsZTogICAgICAgICAgICAgICAgICAgICAgSGVhZGVyIENvbXByZXNzaW9uIGZv ciBIVFRQL1FVSUMNCg0KPg0KDQo+IERvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAgMjAxNy0w MS0xNw0KDQo+DQoNCj4gR3JvdXA6ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQoNCj4NCg0KPiBQYWdlczogICAgICAgICAgICAgICAgICAgMTANCg0KPg0KDQo+IFVSTDoN Cg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmlzaG9wLXF1 aWMtaHR0cC1hbmQtcXBhY2stDQoNCj4gMDEudHh0DQoNCj4NCg0KPiBTdGF0dXM6DQoNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQt cXBhY2svDQoNCj4NCg0KPiBIdG1saXplZDoNCg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2stMDENCg0KPg0KDQo+IERpZmY6DQoN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJpc2hvcC1xdWljLWh0 dHAtYW5kLXFwYWNrLTAxDQoNCj4NCg0KPg0KDQo+DQoNCj4gQWJzdHJhY3Q6DQoNCj4NCg0KPiAg ICBIVFRQLzIgW1JGQzc1NDBdIHVzZXMgSFBBQ0sgW1JGQzc1NDFdIGZvciBoZWFkZXIgY29tcHJl c3Npb24uDQoNCj4NCg0KPiAgICBIb3dldmVyLCBIUEFDSyByZWxpZXMgb24gdGhlIGluLW9yZGVy IG1lc3NhZ2UtYmFzZWQgc2VtYW50aWNzIG9mDQoNCj4gdGhlDQoNCj4NCg0KPiAgICBIVFRQLzIg ZnJhbWluZyBsYXllciBpbiBvcmRlciB0byBmdW5jdGlvbi4gIE1lc3NhZ2VzIGNhbiBvbmx5IGJl DQoNCj4NCg0KPiAgICBzdWNjZXNzZnVsbHkgZGVjb2RlZCBpZiBwcm9jZXNzZWQgYnkgdGhlIGRl Y29kZXIgaW4gdGhlIHNhbWUgb3JkZXINCg0KPiBhcw0KDQo+DQoNCj4gICAgZ2VuZXJhdGVkIGJ5 IHRoZSBlbmNvZGVyLiAgVGhpcyBkcmFmdCByZWZpbmVzIEhQQUNLIHRvIGxvb3NlbiB0aGUNCg0K Pg0KDQo+ICAgIG9yZGVyaW5nIHJlcXVpcmVtZW50cyBmb3IgdXNlIG92ZXIgUVVJQyBbSS1ELmll dGYtcXVpYy10cmFuc3BvcnRdLg0KDQo+DQoNCj4NCg0KPg0KDQo+DQoNCj4NCg0KPg0KDQo+DQoN Cj4NCg0KPg0KDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mDQoNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQo+DQoN Cj4NCg0KPg0KDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCj4NCg0KPg0K --_000_BN6PR03MB270853D7DBA48E58602BC32B877E0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNDU3NzEzNzU7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjY1NTk0MTU4IDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+WWVzLCBRUEFDSy1BQ0sgaXMgb24gdGhlIGNvbm5lY3Rpb24gY29udHJvbCBzdHJl YW0sIHdoaWNoIGlzIHN0cmVhbSAzOyB0aGF0J3MgbWVudGlvbmVkIGJ5IG5hbWUsIGJ1dCBub3Qg Ynkgc3RyZWFtIG51bWJlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gYW4gdW5w dWJsaXNoZWQgcHJldmlvdXMgdmVyc2lvbiwgdGhlIEFDSyB3YXMgYSBiaXRtYXAgb2YgYWxsIHNs b3RzIGluIHRoZSB0YWJsZSwgaW5kaWNhdGluZyBvY2N1cGllZCBvciBub3QsIGFzIHlvdSBzdWdn ZXN0LiZuYnNwOyBXaGF0IGNhdXNlZCBpdCB0byBjaGFuZ2UgaXMgdGhpcyB1bmxpa2VseS1idXQt cG9zc2libGUgc2NlbmFyaW86PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PkVuY29kZXIgaW5zZXJ0cyB0byBzbG90IEE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGlz IGZyYW1lIGlzIGRlbGF5ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ RW5jb2RlciBkZWxldGVzIHNsb3QgQTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoaXMgZnJh bWUgaXMgPGk+YWxzbzwvaT4gZGVsYXllZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5FbmNvZGVyIHJlY2VpdmVzIGEgUVBBQ0stQUNLIGluZGljYXRpbmcgdGhhdCBBIGlz IGVtcHR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkF0IHRoaXMgcG9pbnQsIHdpdGhv dXQgcXVlcnlpbmcgdGhlIHRyYW5zcG9ydCB0byBzZWUgd2hpY2ggZnJhbWVzIGhhdmUvaGF2ZW7i gJl0IGJlZW4gYWNrbm93bGVkZ2VkLCB0aGUgZW5jb2RlciBkb2VzbuKAmXQga25vdyB3aGV0aGVy IGRlbGV0ZShBKSBoYXMgY29tcGxldGUgc3VjY2Vzc2Z1bGx5LCBvciBpbnNlcnQoQSkgaGFzbuKA mXQgaGFwcGVuZWQgeWV0LiZuYnNwOyBJbiBvcmRlciB0byBtaXRpZ2F0ZSB0aGF0LCB0aGUNCiBl bmNvZGVyIG9yaWdpbmFsbHkgd2FzbuKAmXQgYWxsb3dlZCB0byBzZW5kIGRlbGV0ZShBKSB1bnRp bCBpdCBoYWQgc2VlbiBhIFFQQUNLLUFDSyBmcmFtZSBpbmRpY2F0aW5nIHRoZSBzbG90IGFzIG9j Y3VwaWVkLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFsdGVybmF0aXZl bHksIHNpbmNlIHlvdSBrbm93IHRoYXQgc3RyZWFtIDMgaXMgYWx3YXlzIGluIG9yZGVyLCB5b3Ug Y291bGQgc2F5IHRoYXQgeW91IGNhbuKAmXQgY29uc2lkZXIgdGhlIGRlbGV0ZSB0byBoYXZlIG9j Y3VycmVkIHVudGlsIHlvdSBoYXZlIHNlZW4gdGhlIHNsb3QgZmlsbGVkIGluIGF0IGxlYXN0IG9u ZSBRUEFDSy1BQ0ssIHRoZW4gZW1wdHkgaW4gYXQgbGVhc3Qgb25lIFFQQUNLLUFDSy4mbmJzcDsg QnV0DQogdGhlbiBkZWNvZGVycyBoYXZlIHRvIG1ha2Ugc3VyZSBub3QgdG8gc2VuZCBhIFFQQUNL LUFDSyBmcmFtZSB0aGF0IHJlZmxlY3RzIGJvdGggYW4gYWRkIGFuZCBhIGRlbGV0ZSB0byB0aGUg c2FtZSBzbG90LiAmbmJzcDtUaGF0IHNlZW1zIGxpa2UgaXQgZ2V0cyBpbnRvIG1vcmUgcmVjb3Jk a2VlcGluZyB0aGFuIEkgd2FudGVkLCBidXQgbWlnaHQgYmUgYSB2aWFibGUgc29sdXRpb246Jm5i c3A7IEtlZXAgYSBsaXN0IG9mIGFsbCBzbG90cyB3aXRoIGNoYW5nZXMgc2luY2UNCiB5b3VyIGxh c3QgUVBBQ0stQUNLOyBpZiB5b3UgZW5jb3VudGVyIGEgZHVwbGljYXRlIHlvdSBNVVNUIGVtaXQg dGhlIFFBIGZyYW1lIGFuZCBtYWtlIHRoZSBkdXBsaWNhdGUgdGhlIGZpcnN0IGNoYW5nZSBhY2N1 bXVsYXRpbmcgdG93YXJkIHlvdXIgbmV4dCBRUEFDSy1BQ0suPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkJ5IHN3aXRjaGluZyB0byBhbiBpbmNyZW1lbnRhbCBRUEFDSy1BQ0ssIHRoZSBz dGF0ZSBtYWNoaW5lIGJlY29tZXMgcmVhbGx5IHNpbXBsZSDigJMgZW5jb2RlcnMganVzdCBpbnNl cnQgYW5kIHRydXN0IHRoYXQgdGhlIGRlbGV0ZSBjb3VudGVyIHdpbGwgY292ZXIgaXQuJm5ic3A7 IERlY29kZXJzIGNhbiBhY2N1bXVsYXRlIGFzIG11Y2ggYXMgdGhleSB3YW50IGludG8gYSBzaW5n bGUgUVBBQ0stQUNLIGZyYW1lLCBiZWNhdXNlDQogdGhlIHNlbmRlciBpc27igJl0IGFsbG93ZWQg dG8gaXNzdWUgaW5zdHJ1Y3Rpb25zIHRoYXQgd291bGQgZ2VuZXJhdGUgZHVwbGljYXRlcy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGZhY3QgdGhhdCBpbnNlcnRzIG1pZ2h0IGhh dmUgYmVlbiBsb3N0IGR1ZSB0byBhIHJlc2V0IGlzIGEgd3JpbmtsZSBJIGhhZG7igJl0IGNvbnNp ZGVyZWQsIGFuZCBub3Qgb25lIEkgaGF2ZSBhIHJlYWR5IHNvbHV0aW9uIHRvLiBUaGF04oCZcyBh IHNlcmlvdXMgaXNzdWUgYXBwbGljYWJsZSB0byBIUEFDSyBpbiB0aGUgY3VycmVudCBkcmFmdCAt MDEgYXMgd2VsbC4mbmJzcDsgV2XigJlsbCBoYXZlIHRvIHRoaW5rIGFib3V0DQogdGhhdCBvbmUg 4oCTIHRoZXJlIGFyZSBhIGxvdCBvZiBicmlnaHQgcGVvcGxlIGhlcmUsIHNvIEnigJltIHN1cmUg c29tZW9uZSB3aWxsIGNvbWUgdXAgd2l0aCBzb21ldGhpbmcuJm5ic3A7IElmIG5vdGhpbmcgZWxz ZSwgZ2l2ZW4gdGhhdCBoZWFkZXJzIGFyZQ0KPGk+dXN1YWxseTwvaT4gc21hbGwsIHdlIGNvdWxk IHNheSB0aGF0IG9ubHkgdGhlIGRhdGEgc3RyZWFtcyBnZXQgUlNULCBuZXZlciB0aGUgaGVhZGVy IHN0cmVhbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb21dIDxicj4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxNyA3OjI5 IFBNPGJyPg0KVG86IE1pa2UgQmlzaG9wICZsdDtNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t Jmd0Ozxicj4NCkNjOiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3Vi amVjdDogUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJpc2hvcC1x dWljLWh0dHAtYW5kLXFwYWNrLTAxLnR4dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIGZvciBw dXR0aW5nIHRoaXMgdG9nZXRoZXIgTWlrZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSB0aGluayB0aGF0IHRoaXMgaXMgdGhlIHJpZ2h0IGRpcmVjdGlvbiB0byBnbyBmb3IgUVVJQy4m bmJzcDsgSXQgaXMgbWFyZ2luYWxseSBtb3JlIGNvbXBsZXggdGhhbiBIUEFDSywgYnV0IG9ubHkg dG8gdGhlIGV4dGVudCBuZWNlc3NhcnkgKG1vZHVsbyBvbmUgaXNzdWUgYmVsb3cpLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIG5vdGljZSB5b3UgbWVudGlvbiAmcXVvdDtpbmNyZW1l bnRhbCBpbmRleGluZyZxdW90OyBpbiBhIGZldyBwbGFjZXMgc3RpbGwsIHRoYXQgcHJvYmFibHkg bmVlZHMgZml4aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Gb3IgUVBBQ0stQUNL LCBwcmVzdW1hYmx5IHRoaXMgaXMgc2VudCBvbiBzdHJlYW0gMz8yPyZuYnNwOyBJIHRoaW5rIHRo YXQgeW91IHNob3VsZCBpbnZlcnQgdGhlIG1lYW5pbmcgYW5kIG9ubHkgaW5jbHVkZSBiaXRzIGZv ciBlbnRyaWVzIHRoYXQgc3RpbGwgaGF2ZSBhIHZhbHVlIChhdCB0aGUgdGltZSBvZiBzZW5kaW5n KS4mbmJzcDsgVGhpcyBhbGxvd3MgYSBzZW5kZXIgdG8gdmVyaWZ5IHRoYXQgZGVsZXRpb24gaGFz IGhhcHBlbmVkLA0KIGJ1dCBhbHNvIGFsbG93cyB0aGlzIHRvIGJlIGEgY3VtdWxhdGl2ZSBtZXNz YWdlIHJhdGhlciB0aGFuIGFuIGluY3JlbWVudGFsIG9uZS4mbmJzcDsgSXQgbWlnaHQgYWxzbyBh bGxvdyBmb3IgYSBzbWFsbGVyIG1lc3NhZ2UgaWYgYSBzZW5kZXIgcGFja3MgYWxsIHRoZWlyIG1v cmUgc3RhYmxlIHZhbHVlcyBhdCB0aGUgbG93IGVuZCBvZiB0aGUgdGFibGUgLSBkZWxldGVzIGF0 IHRoZSBlbmQgb2YgdGFibGUgZG9uJ3QgbmVlZCB0byBiZSBzaWduYWxlZCBhdA0KIGFsbC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RWRpdG9yaWFsbHksIEkgdGhpbmsgdGhhdCB0aGlz IGlzIHRoZSByaWdodCB3YXkgdG8gcHJlc2VudCB0aGlzIG5vdyBmb3IgdGhlIHdvcmtpbmcgZ3Jv dXAsIGJ1dCB1bHRpbWF0ZWx5IEkgdGhpbmsgdGhhdCBJIHdvdWxkIHByZWZlciB0byBzZWUgYSBt b3JlIHN0YW5kYWxvbmUgZG9jdW1lbnQuJm5ic3A7IElmIHRoYXQgbWVhbnMgcmVwbGljYXRpbmcg dGV4dCBmcm9tIEhQQUNLLCBJIHRoaW5rIHRoYXQgd291bGQgYmUNCiBiZXR0ZXIgdGhhbiBoYXZp bmcgZ2Fwcy4mbmJzcDsgSXQgd291bGQgYWxzbyBnaXZlIHVzIHRoZSBjaGFuY2UgdG8gbWFrZSBz b21lIG9mIHRob3NlIGxvbmctb3V0c3RhbmRpbmcgY2hhbmdlcyB3ZSBwcm9taXNlZCB0byB0aGUg c3RhdGljIHRhYmxlOyBtYXliZSBldmVuIGluZm9ybWVkIGJ5IG5ldyBhbmQgbW9yZSByZWxldmFu dCBkYXRhIGZyb20gaDIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFuIGlzc3VlIHRo YXQgbmVlZHMgc29tZSB0aG91Z2h0OiBhIHJlc2V0IHN0cmVhbSBtaWdodCBpbmNsdWRlIGEgcmVm ZXJlbmNlIHRvIGFuIGluZGV4IGVudHJ5LiZuYnNwOyBIb3dldmVyIHRoYXQgcmVmZXJlbmNlIHdv bid0IGJlIHJlcGFpcmVkIGluIHRoZSBldmVudCBvZiBsb3NzIGFmdGVyIGEgcmVzZXQuJm5ic3A7 IFdlIG5lZWQgYSBzdHJhdGVneSBmb3IgZGVhbGluZyB3aXRoIHRoYXQgYW5kIEkgY2FuJ3QgdGhp bmsgb2YNCiBvbmUgb2ZmaGFuZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBmb3Vu ZCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHN0YXRlcyBhIGxpdHRsZSBjb25mdXNpbmcuJm5ic3A7 IEluIHBhcnRpY3VsYXIsIHRoZSBtaXhpbmcgb2YgZW5jb2RlciBhbmQgZGVjb2RlciBzdGF0ZSBk ZXNjcmlwdGlvbnMgd2FzIGhhcmQgdG8gZm9sbG93LiZuYnNwOyBTZXBhcmF0aW5nIHRob3NlIHdv dWxkIGJlIGJldHRlciwgSSB0aGluay4mbmJzcDsgVGhlIGVuY29kZXIgb25seSBuZWVkcyB0byBr bm93IHdoYXQgZW50cmllcw0KIGV4aXN0LCB3aGF0IGVudHJpZXMgYXJlIGRlYWQgYnV0IGNvbnN1 bWluZyBzcGFjZSwgYW5kIHdoYXQgZW50cmllcyBhcmUgZnJlZS4mbmJzcDsgVGhlIGRlY29kZXIg bmVlZHMgbW9yZSBwcmVjaXNlIGFjY291bnRpbmcgYWJvdXQgdGhlIG51bWJlciBvZiB1c2VzIGFu ZCB3aGVuIHRoZSB1c2VzIGhpdCBhIGRlbGV0ZSB0aHJlc2hvbGQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoZSBhY3R1YWwgYWxnb3JpdGhtIGNhbiBiZSBxdWl0ZSBlbGVnYW50OiBB dCB0aGUgZGVjb2RlciwgY291bnRlcnMgZm9yIHVzZV9jb3VudCBhbmQgZGVsZXRlX2NvdW50LCBw bHVzIHRoZSBzbG90cyBmb3IgbmFtZSBhbmQgdmFsdWUsIGFyZSBzdWZmaWNpZW50LiZuYnNwOyBJ IHRoaW5rIHRoYXQncyBhbGwgeW91IG5lZWQgYXNpZGUgZnJvbSBtYXliZSBhbiBpbmRleCBudW1i ZXIgc2xvdCwgc28gaXQncyBwcm9iYWJseQ0KIE9LIG5vdCB0byBjaGFuZ2UgdGhlIDMyIG9jdGV0 LXBlci1lbnRyeSBhbGxvd2FuY2UgZnJvbSBIUEFDSywgZXZlbiB0aG91Z2ggeW91IG5lZWQgdG8g YWRkIHRoZXNlIGNvdW50ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIHZhbHVl IG9mIDAgZm9yIHVzZV9jb3VudCBpbmRpY2F0ZXMgdGhhdCB0aGUgZmllbGQgaXMgdW51c2VkIGFu ZCBjYW4gYmUgYWxsb2NhdGVkIHRvIHNhZmVseS4mbmJzcDsgQSB2YWx1ZSBvZiAwIGZvciBkZWxl dGVfY291bnQgaW5kaWNhdGVzIHRoYXQgYSBkZWxldGUgaGFzbid0IGJlZW4gcmVxdWVzdGVkLiZu YnNwOyBXaGVuIGFuIGluc2VydCBvciByZWZlcmVuY2UgaGFwcGVucyAoaW5jbHVkaW5nIHRoZSBm aXJzdCBpbnNlcnQpOg0KICYjNDM7JiM0Mzt1c2VfY291bnQ7IHdoZW4gYSBkZWxldGUgaXMgcmVx dWVzdGVkLCBzZXQgZGVsZXRlX2NvdW50LiZuYnNwOyBJbiBib3RoIGNhc2VzLCBhbHNvIGFkZCBh IGNoZWNrIGZvciBkZWxldGVfY291bnQgPT0gdXNlX2NvdW50LCBpbiB3aGljaCBjYXNlIHlvdSBm cmVlIHRoZSBlbnRyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGVuY29kZXIg ZG9lc24ndCBuZWVkIHRvIHVzZSB0aGUgZGVsZXRlX2NvdW50LCBidXQgaXQgZG9lcyBuZWVkIHRv IHJlbWVtYmVyIHRoYXQgdGhlIHNsb3QgZXhpc3RlZCBwcmV2aW91c2x5IC0gYW5kIGhvdyBiaWcg aXQgd2FzIC0gc28gdGhhdCBpdCBkb2Vzbid0IHJldXNlIGl0IGJlZm9yZSB0aGUgZGVjb2RlciBj b25maXJtcyB0aGF0IGl0J3MgT0sgdG8gZG8gc28uJm5ic3A7IFN3aXRjaGluZyBkZWxldGVfY291 bnQNCiBmb3IgYSBzaXplIGNvdW50ZXIgd291bGQgZG8gZm9yIHRoYXQgcHVycG9zZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlcmUncyBub3RoaW5nIHByZXZlbnRpbmcgYW4gZW5j b2RlciBmcm9tIHVzaW5nIGhpZ2ggaW5kZXggbnVtYmVycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlRoYXQgY291bGQgYmUgcXVpdGUgaW5lZmZpY2llbnQgYW5kIHBv dGVudGlhbGx5IGRhbmdlcm91cyBmb3IgYSBkZWNvZGVyIHRoYXQgd2Fzbid0IHByZXBhcmVkIGZv ciBpdC4mbmJzcDsgRG8gd2UgbmVlZCBhIGNhcCBvbiB0aGUgaW5kZXggdmFsdWUganVzdCB0byBw cmV2ZW50IHNpbGxpbmVzcz8mbmJzcDsgKHRhYmxlX3NpemUgLzMyKSB3b3VsZCBiZSB0aGUgYWJz b2x1dGUgbGFyZ2VzdCBzZW5zaWJsZSB2YWx1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+T24gMTggSmFudWFyeSAyMDE3IGF0IDEzOjA3LCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0i bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQu Y29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBXaXRoIHRoZSByZWNlbnQgcHVibGljYXRpb24gb2YgdGhlIFdHIC0wMSBk cmFmdHMsIEkndmUgdXBkYXRlZCBteQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IFFQQUNLIGRyYWZ0IHRvIC0wMSBhcyB3ZWxsLiZuYnNwOyBOb3RhYmxlIG5v bi1lZGl0b3JpYWwgY2hhbmdlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgUmVhbGl6ZWQgd2UgZGlkbuKAmXQgbmVlZCB0aGUgYWJpbGl0eSBmb3IgdGhlIGVuY29kZXIg dG8gZGVjbGFyZSBhIHRhYmxlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgc2l6ZSBpZiB0aGUgZW5jb2RlciBpcyBleHBsaWNpdGx5IG1hbmFnaW5nIHRoZSB0 YWJsZS4mbmJzcDsgVGhlcmVmb3JlLCBJDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgY2FuIHN0ZWFsIHRoZSDigJxzaXplIGNoYW5nZeKAnSBpbnN0cnVjdGlv biByYXRoZXIgdGhhbiB0aGUg4oCcbmV2ZXItaW5kZXhlZOKAnSBpbnN0cnVjdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUmVzb2x2ZXMgb25lIG9mIHRo ZSBtYWpvciBkcmF3YmFja3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IFJlbW92ZWQgdGhlIHByb3Bvc2VkIEhUVFAvUVVJQyBtYXBwaW5nLCBzaW5jZSB0aGF0 4oCZcyBub3cgbGFyZ2VseQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGluY29ycG9yYXRlZCBpbnRvIHRoZSBXRyBkb2N1bWVudC4mbmJzcDsgUmVwbGFjZWQg d2l0aCBhIG11Y2ggc2hvcnRlcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IHNlY3Rpb24gb24gaG93IHRvIHNsb3QgUVBBQ0sgaW50byBocS0wMS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2xhcmlmaWVkIGhvdyBjaGFu Z2VzIHRvIG1heGltdW0gdGFibGUgc2l6ZSBkdXJpbmcgYSBsaXZlIGNvbm5lY3Rpb24NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcmUgaGFuZGxlZCwgZXNw ZWNpYWxseSBpbiBsaWdodCBvZiB0aGUgc2V0dGluZ3Mtc3luY2hyb25pemF0aW9uIHRleHQNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGF04oCZcyBiZWVu IGFkZGVkIHRvIGhxLTAxLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPC9zcGFuPjwvYT4gWzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT5dPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNlbnQ6IFR1ZXNkYXksIEphbnVh cnkgMTcsIDIwMTcgNDowMSBQTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBUbzogTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hv cEBtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAxLnR4dDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1h bmQtcXBhY2stMDEudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlrZSBCaXNob3AgYW5kIHBvc3RlZCB0 byB0aGUgSUVURg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE5hbWU6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAt YW5kLXFwYWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFJldmlzaW9u OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBUaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSGVhZGVyIENvbXByZXNzaW9uIGZvciBIVFRQL1FV SUM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRG9jdW1lbnQgZGF0ZTom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNy0wMS0xNzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBHcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IFBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAxMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBVUkw6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iaXNob3At cXVpYy1odHRwLWFuZC1xcGFjay0iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAwMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgU3RhdHVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay8iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLzwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEh0bWxpemVkOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2stMDEiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay0wMTwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IERpZmY6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1x cGFjay0wMSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJpc2hvcC1xdWlj LWh0dHAtYW5kLXFwYWNrLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg QWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEhUVFAvMiBbUkZDNzU0MF0gdXNlcyBIUEFDSyBbUkZDNzU0MV0gZm9yIGhlYWRl ciBjb21wcmVzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsgSG93ZXZlciwgSFBBQ0sgcmVsaWVzIG9uIHRoZSBpbi1vcmRlciBtZXNz YWdlLWJhc2VkIHNlbWFudGljcyBvZg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBIVFRQLzIgZnJhbWluZyBsYXllciBpbiBvcmRlciB0byBmdW5jdGlv bi4mbmJzcDsgTWVzc2FnZXMgY2FuIG9ubHkgYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VjY2Vzc2Z1bGx5IGRlY29kZWQgaWYgcHJv Y2Vzc2VkIGJ5IHRoZSBkZWNvZGVyIGluIHRoZSBzYW1lIG9yZGVyDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZ2VuZXJhdGVkIGJ5IHRoZSBlbmNvZGVy LiZuYnNwOyBUaGlzIGRyYWZ0IHJlZmluZXMgSFBBQ0sgdG8gbG9vc2VuIHRoZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvcmRlcmluZyBy ZXF1aXJlbWVudHMgZm9yIHVzZSBvdmVyIFFVSUMgW0ktRC5pZXRmLXF1aWMtdHJhbnNwb3J0XS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZSBJRVRGIFNlY3JldGFy aWF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB270853D7DBA48E58602BC32B877E0BN6PR03MB2708namp_-- From nobody Wed Jan 18 23:47: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 B39EA128B37 for ; Wed, 18 Jan 2017 23:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsivVViqzljC for ; Wed, 18 Jan 2017 23:46:57 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F0C120726 for ; Wed, 18 Jan 2017 23:46:56 -0800 (PST) X-AuditID: c1b4fb2d-9dbff7000000646e-c7-58806eedf972 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 64.60.25710.DEE60885; Thu, 19 Jan 2017 08:46:55 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 19 Jan 2017 08:46:53 +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=8YH/nG7+UnPU+vrNdhrtyt3QmX1ypMcYgNCIWITHVZU=; b=eU5eyH4E1TaACTHRUyOvenI0rKOLS908AeJ6rT0FvEb89x+LqRbr09ZCtyMprGg06QPJAVmYQLg7D1P74ZIapoGGnJsB3bAORPFn+NT1UK74O1K9TzLBusDU9oAbHPWypfFV0CDZYQh90DHy88QceaWwQfSgdMsY3HFemM4yMzY= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 07:46:52 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0860.012; Thu, 19 Jan 2017 07:46:52 +0000 From: Ingemar Johansson S To: "quic@ietf.org" Subject: New Version Notification for draft-johansson-quic-ecn-00.txt Thread-Topic: New Version Notification for draft-johansson-quic-ecn-00.txt Thread-Index: AdJyJtbaKLtxcYDBSdSPd55jJ/SaqQ== Date: Thu, 19 Jan 2017 07:46:52 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:CSUQqtVDaF8QpGeNQZGZsh9cJuCQxqBznjJchd17+BIKNNEqwSu5asyyNCFhzcsDpJM9fBp/Yw/jaycOykDXHVjAxKOYbrk7D5SfqHYWN8SqolxbNjjeO++oyV7VV3ZDMiSQbjHdPr5hCtLXz8ClFLzFPWqfp+oQUscfjVeaQC0Zz/2pbWSDuWSODSadn2hcW7mbTCezDvbjG0skeWz1RotsaqQDYXhy8oFXQ+GsnoR+7ycpfROS62z7SeP74DJq5Hp3l2Y3RaLE5FyBY2CxwHp2qfx1tmRA3/El7CWODVuei6+JVqfmhJEIOUDhy3OrrC6TNSYvU7lu3mjvaXOYSD9Bghl8vq7U+Z1W4NzW0R0ieYRR9fdXJJcO3HhGWCtqTOhhrr4m8rOyMK1Z6pOiIebHMbkyVc1UFOTWX0Te6JudG7/zO3oTu+o/qnFfZzKGFXUME3DvcZZ0QTx4jTQmlQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(66654002)(51914003)(189002)(377424004)(199003)(189998001)(19609705001)(107886002)(9326002)(4326007)(2501003)(92566002)(2906002)(450100001)(236005)(1730700003)(81156014)(81166006)(8936002)(8676002)(53936002)(66066001)(106356001)(86362001)(102836003)(790700001)(2900100001)(3846002)(6116002)(105586002)(2351001)(97736004)(77096006)(606005)(6436002)(6506006)(33656002)(101416001)(3280700002)(38730400001)(230783001)(25786008)(6306002)(5640700003)(9686003)(54896002)(55016002)(99286003)(50986999)(5630700001)(3660700001)(6916009)(122556002)(110136003)(7696004)(5660300001)(54356999)(68736007)(4001430100002)(74316002)(7906003)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 184d94ff-5d05-4a30-ef28-08d4403f555c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 0192E812EC received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3482E7746406BF03EF70693C27E0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 07:46:52.4182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUyM2J7iO77vIYIgzdnRCx6FnA7MHosWfKT KYAxissmJTUnsyy1SN8ugSvj2c93LAU90RWX7l5gaWB8E9jFyMkhIWAicf/3OfYuRi4OIYF1 jBLHOlcyQjgnGCX+vPjJBOKwCPQyS5ybdgMqM5VJYkL3N6ieY4wSC5q2MIEMYxOwkVh56Dsj iC0ioCwxZ+lidhCbWcBK4svxv8wgtrCAq8TuKStYIGq8JPpnfWaHsPUk7izrBOtlEVCV6Nl9 A8zmFYiSWHDjAZjNKCArcf/7PRaImeISt57MZ4J4QkBiyZ7zzBC2qMTLx/9YIeqTJT7d7AWy OYDiChIPt/qB3Cwh0M0i8XzxFHYI5wqbxOuzu6GafSV+XzzNAmH7SLxvWcEG0ZwpMfGsHEQ4 R2LF672MEL0dTBKbNj2D6pWRmDi1G2yxkECqxPK1rYwQD0tJ3L3SCWXLSLy4s5cV4oF8idu7 vrBOYFSfheSfWUhSs8D+F5Q4OfMJC0RcT+LG1ClsELa2xLKFr5khbF2JGf8OsSCLL2BkX8Uo WpxaXJybbmSsl1qUmVxcnJ+nl5dasokRmGoObvmtu4Nx9WvHQ4wCHIxKPLwfmuojhFgTy4or cw8xSnAwK4nwOuc0RAjxpiRWVqUW5ccXleakFh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgm y8TBKdXAuL7tZduVE4d6Mm6Ed655dSLTbEpe9zoWG7306KinJx30Uz9/mBUuwuz96rY504HI /Sc9l9pqNPiWrhXV2Xe+btfCoG+bFZuihGTuLS83YJTruxTGNeeU8lMOxfrMxTOie+ayb5/G 9ziL48Daq94RhrmLcmQ6Y3Xyaw6pNFr6FXostzfyX3NeiaU4I9FQi7moOBEAZxLSnTEDAAA= Archived-At: Cc: Ingemar Johansson S X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 19 Jan 2017 07:47:00 -0000 --_000_DB4PR07MB3482E7746406BF03EF70693C27E0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi This draft, that outlines the ECN support in QUIC, is the result of some em= ail exchange with mainly Mirja K=FChlewind, Koen De Schepper and Michael We= lzl, many thanks for the valuable input. The draft outlines the different aspects such as "negotiation", fallback an= d protocol aspects. Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D A new version of I-D, draft-johansson-quic-ecn-00.txt has been successfully= submitted by Ingemar Johansson and posted to the IETF repository. Name: draft-johansson-quic-ecn Revision: 00 Title: ECN support in QUIC Document date: 2017-01-18 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-johansson-quic-e= cn-00.txt Status: https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/ Htmlized: https://tools.ietf.org/html/draft-johansson-quic-ecn-00 Abstract: This memo outlines the ECN support in QUIC. The intention is that most of the material ends up updating other new or existing QUIC protocol specifications, thus it may be possible that this draft does not warrant a working group status. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com No, you can=B4t tell people anything You've got to show 'em Bruce Springsteen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB3482E7746406BF03EF70693C27E0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

This draft, that outlines the ECN support in QUIC, i= s the result of some email exchange with mainly Mirja K=FChlewind, Koen De = Schepper and Michael Welzl, many thanks for the valuable input.

The draft outlines the different aspects such as = 220;negotiation”, fallback and protocol aspects.

 

Regards

Ingemar

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

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

 

Name:       &n= bsp;          draft-johansson-= quic-ecn

Revision:      &nbs= p;       00

Title:       &= nbsp;           &nbs= p;  ECN support in QUIC

Document date:      = ;         2017-01-18

Group:       &= nbsp;          Individual Subm= ission

Pages:       &= nbsp;           10

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-00.txt

Status:       =   https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/

Htmlized:       https://tools.ietf.org/html/draft-johansson-quic-ecn-00

 

 

Abstract:

   This memo outlines the ECN support i= n QUIC.  The intention is that

   most of the material ends up updatin= g other new or existing QUIC

   protocol specifications, thus it may= be possible that this draft does

   not warrant a working group status.<= o:p>

 

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

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

 =     No, you can=B4t tell people anything

 =         You’ve got to show ‘= em

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

 

--_000_DB4PR07MB3482E7746406BF03EF70693C27E0DB4PR07MB348eurprd_-- From nobody Thu Jan 19 01:33: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 893F3128B37 for ; Thu, 19 Jan 2017 01:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCvc1HC71u41 for ; Thu, 19 Jan 2017 01:33:52 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5321E127ABE for ; Thu, 19 Jan 2017 01:33:52 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B19F22E259; Thu, 19 Jan 2017 04:33:33 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Agenda for Next Week's Interim Message-Id: <581171DE-03BB-495A-AD1B-8591AEB7D5A9@mnot.net> Date: Thu, 19 Jan 2017 20:33:30 +1100 To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Lars Eggert X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 19 Jan 2017 09:33:54 -0000 ... is available at: = https://github.com/quicwg/wg-materials/blob/master/interim-17-01/agenda.md= Apologies for the delay. Please have a look, and make sure you're = familiar with both the -01 drafts and the issues list coming into the = meeting. As a reminder, the WG needs to come to consensus on all design issues: = https://github.com/quicwg/base-drafts/issues?q=3Dis%3Aopen%20is%3Aissue%20= label%3Adesign%20 We've flagged a number of issues as needing discussion; please = familiarise yourselves with them.=20 = https://github.com/quicwg/base-drafts/issues?q=3Dis%3Aopen+is%3Aissue+labe= l%3Aneeds-discussion+label%3Adesign And, there are some issues which we believe we have a resolution to, but = consensus needs to be confirmed: = https://github.com/quicwg/base-drafts/issues?q=3Dis%3Aopen%20is%3Aissue%20= label%3Aconfirm-consensus If you'd like to present something about one of the issues, or help out = by summarising it to the group to help start discussion, please contact = Lars or myself before the meeting. We look forward to seeing / hearing you next week! -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jan 19 03:09:52 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 DC61D128B44; Thu, 19 Jan 2017 03:09:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: quic - Update to a Meeting Session Request for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148482419186.10414.3331905204706121474.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 03:09:51 -0800 Archived-At: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 11:09:52 -0000 An update to a meeting session request has just been submitted by Lars Eggert, a Chair of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 250 Conflicts to Avoid: First Priority: irtfopen artarea taps mptcp tcpinc tcpm iccrg tsvwg maprg dispatch httpbis tls saag tsvarea Second Priority: rtcweb webpush acme t2trg Special Requests: Please ping us if you have agenda pressure, to see if we can give up the second slot. --------------------------------------------------------- From nobody Sun Jan 22 18:29: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 4FD7A12956A for ; Sun, 22 Jan 2017 18:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 OyAGr5f0L5Um for ; Sun, 22 Jan 2017 18:29:27 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 174B6129568 for ; Sun, 22 Jan 2017 18:29:27 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id l66so100812669ioi.1 for ; Sun, 22 Jan 2017 18:29:27 -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=aLlOUPQGlTVi4zrVQAmM3S+v1D3CKnDFScGtJoPaYZw=; b=mxRLJT25WYHB03ObpUzYXgjZnIXpJ2z9fVOfG2txgam3/iCbAkrerk84Yu+H+jGszP DqVuEZ8mCNq2hDo5WHexYUFd2pwuFHGnnVWYmVlUImH1y3FLzeEeP51fW9DH9weQwxoR ACr6sZhhbI/tSG0kdVGyNtGzB6LQzsAzNe+4jCTq2Y3v1MKTGr3k/VqJnz5Up66VeqFH yGQHhSFwdy1b/pHjC2B7NiZ1IaJxN6aSV4wAANGnEMFS0mYmVl1MKlzU8vGrAO/S8Brq d3lNQCedjA62bpfpP7aTMKT4rvJH3VRy5qL0ihpSihUw86O0XCbpn8fnO2PhiYljXWOf Tj7Q== 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=aLlOUPQGlTVi4zrVQAmM3S+v1D3CKnDFScGtJoPaYZw=; b=cKR0pMOJbx5KyZwoNzzafQ80+TVAaAf6T7p1YJBoRASBfl8emfpB6oovQr7fdjZmD4 UeBqV4bWq4jMk8rtdBWWWy8hGrHp1H1lJMlETrm3/UFKq8gJiEeQ8K60/+po+77RdUnu pUsBERmcNf4rxxX6HP5/UKwZyBYxII4Q4uo1k0Smi9kKUEQOUDfeVJgcvCR64y+UQT8P 6HKEw/WBAjd64aGrT0U0KzuWOVsOqQKP93ExGBhkTZiwQPk1ahkxDENKehnUr1CECLwc Tq0CSIwnWzgi/yTbO8+oTa6AUNvSAeqjJUMnhh/fajq1eqIywHShcmrik06ZMzypMAgu G+Yg== X-Gm-Message-State: AIkVDXLDiOf0sNqHvGe5sq3VPsgWsijhevYMgoetn2Y8GvK17pQi7SfBjSnX6e61ofjN0cQvAF+QREwlPbvgWg== X-Received: by 10.107.165.146 with SMTP id o140mr15762366ioe.42.1485138566105; Sun, 22 Jan 2017 18:29:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.118.81 with HTTP; Sun, 22 Jan 2017 18:29:25 -0800 (PST) From: "Aron ." Date: Sun, 22 Jan 2017 21:29:25 -0500 Message-ID: Subject: Mapping QUIC version to that included in Alt-Svc header To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1141f0c8acd6cc0546b9c4cd Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 02:29:28 -0000 --001a1141f0c8acd6cc0546b9c4cd Content-Type: text/plain; charset=UTF-8 Hello, A QUIC version is a "32-bit opaque tag." It just so happens that they are currently strings Q034, Q035, and so on. Upon seeing v="34,35" in Alt-Svc header, the client *assumes* that these versions correspond to Q034 and Q035. I do not see this mapping documented anywhere. There has been some recent talk about using new values for experimental QUIC versions. How are they to map to the values advertised in Alt-Svc? Adam. --001a1141f0c8acd6cc0546b9c4cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

A QUIC version is a &= quot;32-bit opaque tag."=C2=A0 It just so happens that they are curren= tly strings Q034, Q035, and so on.=C2=A0 Upon seeing v=3D"34,35" = in Alt-Svc header, the client *assumes* that these versions correspond to Q= 034 and Q035.

I do not see this mapping documented= anywhere.=C2=A0 There has been some recent talk about using new values for= experimental QUIC versions.=C2=A0 How are they to map to the values advert= ised in Alt-Svc?

Adam.
--001a1141f0c8acd6cc0546b9c4cd-- From nobody Sun Jan 22 21:24: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 B0E94129ACF for ; Sun, 22 Jan 2017 21:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD4MtfD_mbQO for ; Sun, 22 Jan 2017 21:24:00 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0118.outbound.protection.outlook.com [104.47.33.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A71129AD2 for ; Sun, 22 Jan 2017 21:24:00 -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=IgFtaszWzpuQUO/k/SjL0pLXvVO9NH1GZVTIstL2GQE=; b=JGOkwRANYvGLOHZRlYptHSzyNx51O7qZ4QZBcGeSPIPPnxoTsf323ml5X9t34HrKsYH8FoqcFJqk+djRTxSaYbus7qoQba3OqaJyseyNT+3nZQO1jKxa0BhMF89uGHJI4zr7qglK5srWFfaxg9NaWXECTObgReLdiH91B5GoYdk= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 05:23:58 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.020; Mon, 23 Jan 2017 05:23:58 +0000 From: Mike Bishop To: "Aron ." , IETF QUIC WG Subject: RE: Mapping QUIC version to that included in Alt-Svc header Thread-Topic: Mapping QUIC version to that included in Alt-Svc header Thread-Index: AQHSdSCJBxhQxTV3UEGmkXIdrFHr/qFFh4pM Date: Mon, 23 Jan 2017 05:23:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:600:8300:3b9a:b84b:bb69:6212:230f] x-ms-office365-filtering-correlation-id: 42a476bf-0059-422c-5571-08d4435008bb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:6fp4uFcdLXtJfSVnUuEWifJEmq0ZYl6zx2D+bNVxMP2mor1e6QnjFQsYu+N4WGC6Wm++TUhO0WqljMrGGV9RTY9sZAZ3EFODtiyFAk7yTO2Os+p74W3vLKfMXrJBx00itkRlmpdlJ2s+ZEooBkMLN8aGR/FMRLM4Hhw11hixih7MR3Ack1mVH6NHFDPqbTqaEeYBBpfe+Bd/uTRfGK77potWeWj9uvSOQrU245TaP4kISo1s3yLVU6USCJ3lp7h6EEJN46R4CPuVtX5E5obhzEFXtyxxm8RXOheEsBue9tiKUfCYTCVlQQYwH3w6umMrFXOnTCKmuhH3sFxMCfSY88IQHYlo0UGdB7nf+VV/K8W8lbjgmCDy4z8zwQtf5ld9jLz48I7rfsK3uyObOWc8cO5EubksB0VNlDDMMcHZgIYUX2QkD9KuNaDEjE1gfUlTeoAdLa14yMxmfFmsqc0dOGxLdSW1vw6M+WnbpwqgBoo= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(6047074); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(377454003)(199003)(189002)(5001770100001)(50986999)(53936002)(236005)(92566002)(7736002)(2900100001)(74316002)(122556002)(8676002)(8990500004)(54356999)(76176999)(97736004)(81156014)(81166006)(8936002)(101416001)(10290500002)(5005710100001)(33656002)(10090500001)(99286003)(9886003)(105586002)(106356001)(106116001)(39060400001)(38730400001)(2906002)(77096006)(229853002)(3660700001)(86362001)(9686003)(54896002)(5660300001)(86612001)(25786008)(189998001)(3900700001)(6116002)(6506006)(102836003)(3280700002)(6436002)(68736007)(7696004)(2950100002)(107886002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708A01B324ED70EE315B93C87720BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 05:23:58.5709 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 05:24:03 -0000 --_000_BN6PR03MB2708A01B324ED70EE315B93C87720BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Look at draft -01 of the HTTP mapping. It proposes a change to the Alt-Svc= mapping to support two different formats of the version, neither if which = requires any client inference. Sent from my Windows 10 phone From: Aron . Sent: Sunday, January 22, 2017 6:29 PM To: IETF QUIC WG Subject: Mapping QUIC version to that included in Alt-Svc header Hello, A QUIC version is a "32-bit opaque tag." It just so happens that they are = currently strings Q034, Q035, and so on. Upon seeing v=3D"34,35" in Alt-Sv= c header, the client *assumes* that these versions correspond to Q034 and Q= 035. I do not see this mapping documented anywhere. There has been some recent = talk about using new values for experimental QUIC versions. How are they t= o map to the values advertised in Alt-Svc? Adam. --_000_BN6PR03MB2708A01B324ED70EE315B93C87720BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Look at draft -01 of the HTTP mapping.  It prop= oses a change to the Alt-Svc mapping to support two different formats of th= e version, neither if which requires any client inference.

 

Sent from my Windows 10 phone

 

From: Aron .
Sent: Sunday, January 22, 2017 6:29 PM
To: IETF QUIC WG
Subject: Mapping QUIC version to that included in Alt-Svc header

 

Hello,

A QUIC version is a "32-bit opaque tag."  It just so ha= ppens that they are currently strings Q034, Q035, and so on.  Upon see= ing v=3D"34,35" in Alt-Svc header, the client *assumes* that thes= e versions correspond to Q034 and Q035.

I do not see this mapping documented anywhere.  There has been so= me recent talk about using new values for experimental QUIC versions. = How are they to map to the values advertised in Alt-Svc?

Adam.
--_000_BN6PR03MB2708A01B324ED70EE315B93C87720BN6PR03MB2708namp_-- From nobody Sun Jan 22 22:08: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 F3BBA129AE1 for ; Sun, 22 Jan 2017 22:08:15 -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 cJsKAuvlAfi0 for ; Sun, 22 Jan 2017 22:08:15 -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 DF8441295A5 for ; Sun, 22 Jan 2017 22:08:14 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id w75so129283498ywg.1 for ; Sun, 22 Jan 2017 22:08:14 -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=2HvjIjujUQQQsU94UjELtfvO0PxCURKiwKusv3xZVac=; b=OuJiXiL57W08xGV6uMJUSPaL4i/seoycuwtFwy1eC/8j4ungfPMH7oTKjgXRWHPHzg sA/TesNQ8kD1jh3MRJmwYEfSzKzHtGx9zqoQdjUFRlQJHIdzxX6x0BkYlbekQwrBiDFV 79VmKy/QiCv8wHgDP9y8bNajk1eg4HJSZCVXcpd88b1kt8sO5LoS/PaSwDVkrNIbbS3b 9aPyQZ1V2lu06k6w7K+VrAIxtehA5hLJCvLQWFwrRmR2cotGddJPA9ueliubnTF8on5U gbZMCPG+RRMAzr74ME1D/y82i517YXmM9Vht02fXNmQJ410piFOfDuZHcO9Hb9RftfGc oX8A== 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=2HvjIjujUQQQsU94UjELtfvO0PxCURKiwKusv3xZVac=; b=DOq2hQgtVCs6PdA27BRnmZeJWg1bNORTrijyL33xzY44ri9T2xU+KnlmkZgVwveq/l hcWVzau4ylx/H8ETRIds4Rltpy0TtZ4YmimudsGS4NYsx0UDwnbyLV98Y0o7n+Q7brng l117XhGO0pQwElbjeGWnw6MqgrvjE3qmfEtSO3IcAxg4nlnNGXZykcjWMiC44Urh2cWx noycOl4VIP9qVHorncz6yDavuL5/hbAkpK6iekQ1cmTBde6SHcq99yCc8uPRv/WfsGSF VPHDz8wzfUmcCSy1Mtb6f4WGXovkhVr9rCFXyIuqK4r62vnu3+3V21esYb9kGU2tKCdd b6GA== X-Gm-Message-State: AIkVDXLOMuK4QKl+s+lNUNI9jzLMv3TXl/2W31IDSVwBWAQo3HrLuf6xHe083Gun7wlQoeFXu6NdDzvvKQjTew== X-Received: by 10.129.125.84 with SMTP id y81mr20237378ywc.120.1485151694115; Sun, 22 Jan 2017 22:08:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Sun, 22 Jan 2017 22:07:33 -0800 (PST) From: Eric Rescorla Date: Sun, 22 Jan 2017 22:07:33 -0800 Message-ID: Subject: HPACK and Header sequence #s To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114928ba2a874e0546bcd3c4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 06:08:16 -0000 --001a114928ba2a874e0546bcd3c4 Content-Type: text/plain; charset=UTF-8 Subject: QUIC and HTTP headers S 4.2.1 of the HTTP draft says: QUIC streams provide in-order delivery of data sent on those streams, but there are no guarantees about order of delivery between streams. To achieve in-order delivery of HEADERS frames in QUIC, the HPACK- bearing frames contain a counter which can be used to ensure in-order processing. Data (request/response bodies) which arrive out of order are buffered until the corresponding HEADERS arrive. This does introduce head-of-line blocking: if the packet containing HEADERS for stream N is lost or reordered then the HEADERS for stream N+4 cannot be processed until it has been retransmitted successfully, even though the HEADERS for stream N+4 may have arrived. As I understand it, you are (effectively) requiring a single stream of data for all the headers. It's not clear to me why it's useful in this case to have the headers on distinct streams from each other as this just seems like it introduces another opportunity for HOL blocking that is harder to fix at the QUIC transport layer because it requires a kind of smarts that is different from that to reduce HOL blocking between packets on the same stream unless the transport either looks into the frames or follows some heuristic about first in first out... -Ekr --001a114928ba2a874e0546bcd3c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Subject: QUIC and HTTP headers

S 4.2.1 of the HTTP draft says:

=C2=A0 =C2=A0QU= IC streams provide in-order delivery of data sent on those streams,
=C2=A0 =C2=A0but there are no guarantees about order of delivery between= streams.
=C2=A0 =C2=A0To achieve in-order delivery of HEADERS fr= ames in QUIC, the HPACK-
=C2=A0 =C2=A0bearing frames contain a co= unter which can be used to ensure in-order
=C2=A0 =C2=A0processin= g.=C2=A0 Data (request/response bodies) which arrive out of order
=C2=A0 =C2=A0are buffered until the corresponding HEADERS arrive.=C2=A0 =C2=A0
=C2=A0 =C2=A0This does introduce head-of-line blo= cking: if the packet containing
=C2=A0 =C2=A0HEADERS for stream N= is lost or reordered then the HEADERS for stream
=C2=A0 =C2=A0N+= 4 cannot be processed until it has been retransmitted successfully,
=C2=A0 =C2=A0even though the HEADERS for stream N+4 may have arrived.

As I understand it, you are (effectively) requiring = a single stream of
data for all the headers. It's not clear t= o me why it's useful in this
case to have the headers on dist= inct streams from each other as this
just seems like it introduce= s another opportunity for HOL blocking
that is harder to fix at t= he QUIC transport layer because it requires
a kind of smarts that= is different from that to reduce HOL blocking
between packets on= the same stream unless the transport either looks
into the frame= s or follows some heuristic about first in
first out...

-Ekr


--001a114928ba2a874e0546bcd3c4-- From nobody Sun Jan 22 23:17:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCDD1295D1 for ; Sun, 22 Jan 2017 23:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=a3IEHadE; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TYzCNC4g Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suTfCUf85aHO for ; Sun, 22 Jan 2017 23:17:03 -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 9B9C21295CC for ; Sun, 22 Jan 2017 23:17:03 -0800 (PST) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.20/8.16.0.20) with SMTP id v0N7GO2M028349; Sun, 22 Jan 2017 23:17:03 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=yNNTzvEccKCpNAskD2Rm6aKp5eRJ7UvETmMkbfaqUD4=; b=a3IEHadEgeZh184nCwBclVS/ySHzHPGIEFXVpGHhUysD9/zAZ1fmCXBLcr6EzZBenfPi FKX10ucj5RijVbKAmxA3YjlimJGCTgc/5dOfBcWfVzfN5cvEmhP5og4wUcQZrFEZTmp7 aOSHLAW2uchzMq6Dw6gWv0bqHDQiHm+SqOA= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 28446k3m7d-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Jan 2017 23:17:03 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.294.0; Sun, 22 Jan 2017 23:17:01 -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=yNNTzvEccKCpNAskD2Rm6aKp5eRJ7UvETmMkbfaqUD4=; b=TYzCNC4gXJA/rua4yHJyC+wquZkQIBnceHvGSLLbW9aveAwjIP6ZzZilGtJuMru1+kFRl3kzNr9YcSsHqHLsMrfSbpKHnWBbR8AG+W63aAVbqh+0hy36XKLgLW1uYz1En9XlETaJ2MA7xgzpFh3fYVytzwSN28JXiUjyycn4Vz8= Received: from BN6PR15MB1299.namprd15.prod.outlook.com (10.172.206.137) by BN6PR15MB1297.namprd15.prod.outlook.com (10.172.206.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 07:16:59 +0000 Received: from BN6PR15MB1299.namprd15.prod.outlook.com ([10.172.206.137]) by BN6PR15MB1299.namprd15.prod.outlook.com ([10.172.206.137]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 07:17:00 +0000 From: Alan Frindell To: Eric Rescorla , IETF QUIC WG Subject: Re: HPACK and Header sequence #s Thread-Topic: HPACK and Header sequence #s Thread-Index: AQHSdT8kBFF7oOSoMUqffpt5CWxQPaFGPb8A Date: Mon, 23 Jan 2017 07:17:00 +0000 Message-ID: <243109C7-BC18-448C-8EE9-46E25F926D3A@fb.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2620:10d:c095:200::1:c99a] x-ms-office365-filtering-correlation-id: 99aca16e-4239-4996-5e51-08d4435fd2a8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR15MB1297; x-microsoft-exchange-diagnostics: 1; BN6PR15MB1297; 7:DygXRq2awt9MMDYpJ2wN4fCe1EjLmTiqFRQW0fdlZ+2z9/+n9QxB8RkzMZKBNGpTdzuYryaSZ8LhdOBDEttHbf5UFKNKuhiYaVY36Tehu+is4ApJ7RI6j61naxkRWVJJTvq9Z6bHHF30xGNRbLtkzYlBzYk44az/l0uZ9aOJ/7/CWlZISPL+L/wf18+sVs40Y7V+vS1ICIMbnEN4n3Ymj+fhKbwq/a34CdatdZ5NPudU8w6T+WSLUP2G+uRYc3XOIe7KDKCFAVl+5jHaHcMeZLQnd5o3dgrDm6FSkkO1Woi3e9iIQWg70CLqC5r4x5VH8RnQDFqhYdPdj/T8Nh84xw+THrl3DQc9aMeusIQl8okfATJLUI9if/MmnUDEWambI2goXbJW8k6kaUMyhmzYAlE8HfJFOS78GJpRim/yO7/4exUhGZbMsqNMBmYANbvqCQw3KAonCM1i3FlUqvIKlg==; 20:LQTDs5NGq2ubaiLH32mqCPLnzvanRMlNbEOhl/qa6cJCo7PtS6Rtl8di6WSUrlL6uOZ5ZkBnu7F/hl8nYMExFFr52HJ1p5EI/Agk2STcubAlL9AFSS0ze5qz9oXSXvg2zyd946ChIiehKDAUQYaIE3BkYaFlhC/J8P1CIuCrAxY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN6PR15MB1297; BCL:0; PCL:0; RULEID:; SRVR:BN6PR15MB1297; x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39830400002)(39410400002)(39450400003)(199003)(189002)(6436002)(38730400001)(25786008)(122556002)(6486002)(6506006)(77096006)(6116002)(229853002)(102836003)(2950100002)(99286003)(106356001)(6512007)(106116001)(105586002)(2906002)(83716003)(8676002)(82746002)(8936002)(81156014)(81166006)(83506001)(3660700001)(305945005)(5001770100001)(2900100001)(76176999)(4001350100001)(54356999)(7736002)(107886002)(101416001)(5660300001)(86362001)(97736004)(50986999)(189998001)(92566002)(68736007)(53936002)(33656002)(3280700002)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR15MB1297; H:BN6PR15MB1299.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: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 07:17:00.0275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1297 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-23_06:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 07:17:05 -0000 PiAgICBBcyBJIHVuZGVyc3RhbmQgaXQsIHlvdSBhcmUgKGVmZmVjdGl2ZWx5KSByZXF1aXJpbmcg YSBzaW5nbGUgc3RyZWFtIG9mDQo+ICAgIGRhdGEgZm9yIGFsbCB0aGUgaGVhZGVycy4gSXQncyBu b3QgY2xlYXIgdG8gbWUgd2h5IGl0J3MgdXNlZnVsIGluIHRoaXMNCj4gICAgY2FzZSB0byBoYXZl IHRoZSBoZWFkZXJzIG9uIGRpc3RpbmN0IHN0cmVhbXMgZnJvbSBlYWNoIG90aGVyIGFzIHRoaXMN Cj4gICAganVzdCBzZWVtcyBsaWtlIGl0IGludHJvZHVjZXMgYW5vdGhlciBvcHBvcnR1bml0eSBm b3IgSE9MIGJsb2NraW5nDQo+ICAgIHRoYXQgaXMgaGFyZGVyIHRvIGZpeCBhdCB0aGUgUVVJQyB0 cmFuc3BvcnQgbGF5ZXIgYmVjYXVzZSBpdCByZXF1aXJlcw0KPiAgICBhIGtpbmQgb2Ygc21hcnRz IHRoYXQgaXMgZGlmZmVyZW50IGZyb20gdGhhdCB0byByZWR1Y2UgSE9MIGJsb2NraW5nDQo+ICAg IGJldHdlZW4gcGFja2V0cyBvbiB0aGUgc2FtZSBzdHJlYW0gdW5sZXNzIHRoZSB0cmFuc3BvcnQg ZWl0aGVyIGxvb2tzDQo+ICAgIGludG8gdGhlIGZyYW1lcyBvciBmb2xsb3dzIHNvbWUgaGV1cmlz dGljIGFib3V0IGZpcnN0IGluDQo+ICAgIGZpcnN0IG91dC4uLg0KDQpJIGFncmVlLiAgSWYgUVVJ QyBpcyBnb2luZyB0byB1c2UgSFBBQ0ssIEkgd291bGQgcHJlZmVyIGFsbCBmcmFtZXMgY29udGFp bmluZyBoZWFkZXIgZGF0YSB0byBiZSBvbiB0aGUgY29ubmVjdGlvbiBjb250cm9sIHN0cmVhbS4N CiANCiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Mon Jan 23 01:00: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 E599D1295D2 for ; Mon, 23 Jan 2017 01:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MtpaGMbS2fo for ; Mon, 23 Jan 2017 01:00:03 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1407E1295DB for ; Mon, 23 Jan 2017 01:00:03 -0800 (PST) Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) by linode64.ducksong.com (Postfix) with ESMTPSA id 81A4B3A021 for ; Mon, 23 Jan 2017 04:00:02 -0500 (EST) Received: by mail-qt0-f172.google.com with SMTP id l7so112839001qtd.1 for ; Mon, 23 Jan 2017 01:00:02 -0800 (PST) X-Gm-Message-State: AIkVDXK49AhYy1qLviqAPxasiLRFBuVMa3Fmc3g8eIUvEwLAuS8kIv9vgU4YzbdIagyoneHzxk2lY/fgFK6OKQ== X-Received: by 10.200.48.65 with SMTP id g1mr22131054qte.94.1485162002331; Mon, 23 Jan 2017 01:00:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Mon, 23 Jan 2017 01:00:01 -0800 (PST) In-Reply-To: <243109C7-BC18-448C-8EE9-46E25F926D3A@fb.com> References: <243109C7-BC18-448C-8EE9-46E25F926D3A@fb.com> From: Patrick McManus Date: Mon, 23 Jan 2017 04:00:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HPACK and Header sequence #s To: Alan Frindell Content-Type: multipart/alternative; boundary=001a1142f5ae955b680546bf393d Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 09:00:05 -0000 --001a1142f5ae955b680546bf393d Content-Type: text/plain; charset=UTF-8 the assumption is we will move towards something like qpack https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack-01 On Mon, Jan 23, 2017 at 2:17 AM, Alan Frindell wrote: > > As I understand it, you are (effectively) requiring a single stream of > > data for all the headers. It's not clear to me why it's useful in this > > case to have the headers on distinct streams from each other as this > > just seems like it introduces another opportunity for HOL blocking > > that is harder to fix at the QUIC transport layer because it requires > > a kind of smarts that is different from that to reduce HOL blocking > > between packets on the same stream unless the transport either looks > > into the frames or follows some heuristic about first in > > first out... > > I agree. If QUIC is going to use HPACK, I would prefer all frames > containing header data to be on the connection control stream. > > > > > > > --001a1142f5ae955b680546bf393d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
the assumption is we will move towards something like qpac= k https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack-01
<= br>

On Mon, = Jan 23, 2017 at 2:17 AM, Alan Frindell <afrind@fb.com> wrote:
>=C2=A0 =C2=A0 As I und= erstand it, you are (effectively) requiring a single stream of
>=C2=A0 =C2=A0 data for all the headers. It's not clear to me why it= 's useful in this
>=C2=A0 =C2=A0 case to have the headers on distinct streams from each ot= her as this
>=C2=A0 =C2=A0 just seems like it introduces another opportunity for HOL= blocking
>=C2=A0 =C2=A0 that is harder to fix at the QUIC transport layer because= it requires
>=C2=A0 =C2=A0 a kind of smarts that is different from that to reduce HO= L blocking
>=C2=A0 =C2=A0 between packets on the same stream unless the transport e= ither looks
>=C2=A0 =C2=A0 into the frames or follows some heuristic about first in<= br> >=C2=A0 =C2=A0 first out...

I agree.=C2=A0 If QUIC is going to use HPACK, I would prefer all fra= mes containing header data to be on the connection control stream.







--001a1142f5ae955b680546bf393d-- From nobody Mon Jan 23 03:37: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 605371295DC for ; Mon, 23 Jan 2017 03:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 Q0hybckz7bc7 for ; Mon, 23 Jan 2017 03:37:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 AEC921294BA for ; Mon, 23 Jan 2017 03:37:30 -0800 (PST) Received: from [192.168.1.123] ([5.10.171.186]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M0cs6-1cFSrk1LV0-00usLJ; Mon, 23 Jan 2017 12:37:22 +0100 Subject: Re: Mapping QUIC version to that included in Alt-Svc header To: Mike Bishop , "Aron ." , IETF QUIC WG References: From: Julian Reschke Message-ID: <92b05e56-f181-276c-5c33-d1cc36b548e7@gmx.de> Date: Mon, 23 Jan 2017 12:37:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wAP9l459XaXQl545SRNwmGJAhgu9e/nJqWIpm9Bo5QjVOWpjc+D ClRoDzo442CC82p00gF1kB5UbEQ1jPl9z7CiaRhjw0rHVSI5lxlYVt2gmjHVs9NYUlB7HyK o1ZCMmcGxl3qZH0RKPefUOPo72BQE2RyeqCJ67ktA286RAB59Vs7CP7ryVSxlvPbqNYyT0H 965GOiRaqCOo3jhu+I0hQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:vlnQzQUruWI=:FgYG7Fg6jhqqqeMF0uhNAl NBT6D+w5WNb6dUZXpQrmzqgA/2GGrlBwc56hH9WlpWJVB0amQ11BTpQ26VA7OI9UGINtpKJr9 dcgKR1tRFQdMhKI6tLURU5FthC0LsMy5tmH/KtSPhEH1wtj76IFti7dVVuPzubg3Od62RS9Tn ZzHdwwzcO872Yxa7DFBD1Z4/EttYddLyDZy23W7Rpj4qWtBc4c77Ps/H3SOFxz6QqAO75R4jf UcWCrjMGOoYTY/4uQdVT58OeHY+RNrnZx7mScNzu3X3tvWDSPOWewy/Q+XxV8ZTtG95z5wjX8 0Chm87aL99d6bnD0QpMuPHAxRbgwGEaCiq70RHhQWFDbO9Ubkd/avXI8lqhXxO2tkH38Qf75s Nh/PUeBPoPdn40P4xYgepYlPTz6IvOTFJsuclo23IGApBteiLbZRRj6QT4oRD1APQF4yegAEg LQmCt7ncIBmDEYxkIncgXAqyaWQySOgxDO+xKVdEPMyRcywXnuIn6n3k8Xvs5a+OK5+FjD/yZ mJG1pKkk4L2gX0FZH87sQG0jwleaP+icPsbYNv4EwcJm0MHqLj6oDB0a2NVdoAeQTWky0Eb7+ d0wpdvDCZkNIK7KsafIintOruyg1GwThUB+AIZIZyMfUGBcRwmIAKvxz7eExSQj4mag1zwmKJ Y/mqMkluhKbIqarFgppBgDrhJPc32HWMKV/wSZ6CZSflPB0Hrw2mNV3Gkp7PX8cyxqiKedtDx FdKfMrnRrs/xjkaSY+FUZ/CdHQtUpoKNEtZE5LLKJhPQZvbYxbu720qqXRmZ82t4kFiLx8Rbp Nq6595Uq/Yu8KgQkRWq04vmW6QRemVWVOfXw2/N++6OMAbs2iBttFdrUBHSDf0O5kyodRyz1U txVk9SeHKIp9Ax9xTgCv6KOLLiXBIxYuS9dyKuIL6HoQnmP5PClSeAYRpALksz/rXpoQguQmp ytiEzT2T1vLXrFu1flZsb7HrxO7CcDsDL8Al7pxwiBcOs8muegQSUH9xqTGrz1cFX9kn/8xcC Br3WP82RQmMrffJPNxqiWDXK9g5hdxJdPdj7YuRJ/MVG3h1Ddic4+Hiw2Fb7cYunSg== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 11:37:32 -0000 On 2017-01-23 06:23, Mike Bishop wrote: > Look at draft -01 of the HTTP mapping. It proposes a change to the > Alt-Svc mapping to support two different formats of the version, neither > if which requires any client inference. > ... : > v = version > version = DQUOTE ( "c" version-string / "x" version-number ) DQUOTE > version-string = token; percent-encoded QUIC version > version-number = 1*8 HEXDIG; hex-encoded QUIC version Nit: this is inconsistent with other uses of quoted-string: 1) It looks like quoted-string, but isn't really (no "\" escaping) 2) It requires quoting when it is not needed. This should be fixed by removing the "version" ABNF. Just state in prose that the value of parameter v (which can be either token or quoted-string) has either the "c" or "x" notation. That said...: > QUIC versions are four-octet sequences with no additional constraints on format. Versions containing octets not allowed in tokens ([RFC7230], Section 3.2.6) MUST be encoded using the hexidecimal representation. Versions containing only octets allowed in tokens MAY be encoded using either representation. This is bad as it means that there are multiple ways to encode the same parameter. IMHO it would be much better just to use format we already use in Alt-Svc; see . Best regards, Julian From nobody Mon Jan 23 09:15: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 F1C5F12968E for ; Mon, 23 Jan 2017 09:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ckrTKBvGfhV for ; Mon, 23 Jan 2017 09:15:04 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0132.outbound.protection.outlook.com [104.47.37.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542381295A8 for ; Mon, 23 Jan 2017 09:15:04 -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=zkbUDfNvhi8dkarxcMYnT99kFgvnnjO5ORlQbg9k/gg=; b=I1T6MQq4Aj12IcYGDT25OMRZ3qTSOKpHT1w/ZHiclm62DwE2osfBmjg358DD3y/IwSBINZeJ80oIwOF9B/EnoCmxwszmt0ZBKTFKlkO2hiQnr4oUFu1HchtUN7N7+Ew5inzMrHQD9zfHHZPhE7R4T6T/JTgiHwlswulgQYKtX0w= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 17:15:02 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 17:15:02 +0000 From: Mike Bishop To: Julian Reschke , "Aron ." , IETF QUIC WG Subject: RE: Mapping QUIC version to that included in Alt-Svc header Thread-Topic: Mapping QUIC version to that included in Alt-Svc header Thread-Index: AQHSdZw7BxhQxTV3UEGmkXIdrFHr/g== Content-Class: urn:content-classes:message Date: Mon, 23 Jan 2017 17:15:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2607:fb90:8343:fcc4:f5cd:6a0:4d0e:6c81] x-ms-office365-filtering-correlation-id: 22591cce-57d9-4be4-5d7c-08d443b35def x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:52gKng+FZOSl9c6gBgUnvD7aU5TdNFidxfpaAYNzhwJIGHOsFrI0G2BaRKFsGUQudTThC733vAEm8rNMDI0uY9GnlIoYnuEcFL2s3VvxCgPUTlzjS7xyzZ04FZLrvYxUdEk6WykgnaX4muiEmrMLIXTTSdoDtjzJtMEpJt1WR2XZeu7Mo4Ebuqi0jP7JrFdkXsgZCfeP2MR2CFD8DqBXIV3Fp4oAJ6UF8yekzA0ebMFwCf0yiAbs8ozfK7J6PY/1ojJ7/9GEaH5k1YBBJPWxiEpGOMCZlsC95nUZGEK0vBF7Y6y5wBqrIHtd+DmiHkE+Y32HSDVg6jfwxP6JfMo/BgSk3BcQ3V/Fo/8AEVkpxl0fg1u4tQt8unieU5Dk5dHP5/zgjE2MW9Ks6QdILbzqLLarbSISx4hGYk75ADGkxCkDvyShhIjmxz5QIGKRV6+uqozN7shhCTEHUy6JAPihoAPXVc8NW87egVifVWgaP5o= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(6047074)(6042181); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(199003)(377454003)(377424004)(24454002)(189002)(10090500001)(101416001)(68736007)(8990500004)(97736004)(102836003)(6116002)(9686003)(92566002)(54356999)(53936002)(50986999)(107886002)(3900700001)(5001770100001)(39060400001)(81156014)(105586002)(106116001)(3660700001)(7696004)(229853002)(38730400001)(3280700002)(106356001)(8676002)(74316002)(81166006)(77096006)(6306002)(189998001)(5005710100001)(2900100001)(305945005)(5660300001)(6506006)(7736002)(6436002)(25786008)(86362001)(99286003)(33656002)(2906002)(86612001)(8666007)(122556002)(10290500002)(55016002)(8936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0E9C91FB45512F4F969ECDD1FFCADE29@microsoft.onmicrosoft.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 17:15:01.8245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 17:15:06 -0000 VGhhdCAocGVyY2VudC1lbmNvZGVkIHRva2VucykgaXMgd2hhdCB0aGUgb3JpZ2luYWwgUFIgY29u dGFpbmVkLiAgVGhlbiBNYXJ0aW4gYW5kIEphbmEgY2FtZSBvdXQgd2l0aCBhIHZlcnNpb25pbmcg c2NoZW1lIGZvciBRVUlDIHdoZXJlIHByYWN0aWNhbGx5IGV2ZXJ5IGNvbW1vbmx5LXVzZWQgdmVy c2lvbiB3b3VsZCByZXF1aXJlIHBlcmNlbnQtZW5jb2RpbmcgYWxsIGZvdXIgYnl0ZXMuICBTbyBJ IGFkZGVkIGEgc3RyYWlnaHQgaGV4IG9wdGlvbiB0byBjb21wYWN0bHkgY292ZXIgdGhvc2UgY2Fz ZXMuICAoTWFydGluIGlzIGFyZ3VpbmcgZm9yIGhleC1vbmx5LCBhbmQgbGV0IHRoZSBleGlzdGlu ZyBwc2V1ZG8tQVNDSUkgdmVyc2lvbnMgYmUgdGhlIG9uZXMgdG8gc3VmZmVyLiAgSGUncyBhbHNv IGdpdmVuIHRoZSBzYW1lIGRvbid0LW5lZWQtcXVvdGVzIGZlZWRiYWNrLCBhbmQgSeKAmWxsIHJl bW92ZSB0aGVtIGluIHRoZSBuZXh0IHJldi4pDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIDEwIHBo b25lDQoNCkZyb206IEp1bGlhbiBSZXNjaGtlDQpTZW50OiBNb25kYXksIEphbnVhcnkgMjMsIDIw MTcgMzozNyBBTQ0KVG86IE1pa2UgQmlzaG9wOyBBcm9uIC47IElFVEYgUVVJQyBXRw0KU3ViamVj dDogUmU6IE1hcHBpbmcgUVVJQyB2ZXJzaW9uIHRvIHRoYXQgaW5jbHVkZWQgaW4gQWx0LVN2YyBo ZWFkZXINCg0KT24gMjAxNy0wMS0yMyAwNjoyMywgTWlrZSBCaXNob3Agd3JvdGU6DQo+IExvb2sg YXQgZHJhZnQgLTAxIG9mIHRoZSBIVFRQIG1hcHBpbmcuICBJdCBwcm9wb3NlcyBhIGNoYW5nZSB0 byB0aGUNCj4gQWx0LVN2YyBtYXBwaW5nIHRvIHN1cHBvcnQgdHdvIGRpZmZlcmVudCBmb3JtYXRz IG9mIHRoZSB2ZXJzaW9uLCBuZWl0aGVyDQo+IGlmIHdoaWNoIHJlcXVpcmVzIGFueSBjbGllbnQg aW5mZXJlbmNlLg0KPiAuLi4NCg0KPGh0dHBzOi8vZ3JlZW5ieXRlcy5kZS90ZWNoL3dlYmRhdi9k cmFmdC1pZXRmLXF1aWMtaHR0cC0wMS5odG1sI3JmYy5zZWN0aW9uLjIuMT46DQoNCj4gdiA9IHZl cnNpb24NCj4gdmVyc2lvbiA9IERRVU9URSAoICJjIiB2ZXJzaW9uLXN0cmluZyAvICJ4IiB2ZXJz aW9uLW51bWJlciApIERRVU9URQ0KPiB2ZXJzaW9uLXN0cmluZyA9IHRva2VuOyBwZXJjZW50LWVu Y29kZWQgUVVJQyB2ZXJzaW9uDQo+IHZlcnNpb24tbnVtYmVyID0gMSo4IEhFWERJRzsgaGV4LWVu Y29kZWQgUVVJQyB2ZXJzaW9uDQoNCk5pdDogdGhpcyBpcyBpbmNvbnNpc3RlbnQgd2l0aCBvdGhl ciB1c2VzIG9mIHF1b3RlZC1zdHJpbmc6DQoNCjEpIEl0IGxvb2tzIGxpa2UgcXVvdGVkLXN0cmlu ZywgYnV0IGlzbid0IHJlYWxseSAobm8gIlwiIGVzY2FwaW5nKQ0KDQoyKSBJdCByZXF1aXJlcyBx dW90aW5nIHdoZW4gaXQgaXMgbm90IG5lZWRlZC4NCg0KVGhpcyBzaG91bGQgYmUgZml4ZWQgYnkg cmVtb3ZpbmcgdGhlICJ2ZXJzaW9uIiBBQk5GLiBKdXN0IHN0YXRlIGluIHByb3NlIA0KdGhhdCB0 aGUgdmFsdWUgb2YgcGFyYW1ldGVyIHYgKHdoaWNoIGNhbiBiZSBlaXRoZXIgdG9rZW4gb3IgDQpx dW90ZWQtc3RyaW5nKSBoYXMgZWl0aGVyIHRoZSAiYyIgb3IgIngiIG5vdGF0aW9uLg0KDQpUaGF0 IHNhaWQuLi46DQoNCj4gUVVJQyB2ZXJzaW9ucyBhcmUgZm91ci1vY3RldCBzZXF1ZW5jZXMgd2l0 aCBubyBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9uIGZvcm1hdC4gVmVyc2lvbnMgY29udGFpbmlu ZyBvY3RldHMgbm90IGFsbG93ZWQgaW4gdG9rZW5zIChbUkZDNzIzMF0sIFNlY3Rpb24gMy4yLjYp IE1VU1QgYmUgZW5jb2RlZCB1c2luZyB0aGUgaGV4aWRlY2ltYWwgcmVwcmVzZW50YXRpb24uIFZl cnNpb25zIGNvbnRhaW5pbmcgb25seSBvY3RldHMgYWxsb3dlZCBpbiB0b2tlbnMgTUFZIGJlIGVu Y29kZWQgdXNpbmcgZWl0aGVyIHJlcHJlc2VudGF0aW9uLg0KDQpUaGlzIGlzIGJhZCBhcyBpdCBt ZWFucyB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHRvIGVuY29kZSB0aGUgc2FtZSANCnBh cmFtZXRlci4NCg0KSU1ITyBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciBqdXN0IHRvIHVzZSBmb3Jt YXQgd2UgYWxyZWFkeSB1c2UgaW4gDQpBbHQtU3ZjOyBzZWUgDQo8aHR0cHM6Ly9ncmVlbmJ5dGVz LmRlL3RlY2gvd2ViZGF2L3JmYzc4MzguaHRtbCNyZmMuc2VjdGlvbi4zLnAuND4uDQoNCkJlc3Qg cmVnYXJkcywgSnVsaWFuDQo= From nobody Mon Jan 23 09:25: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 7FDC0129665 for ; Mon, 23 Jan 2017 09:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZZuIHCuY9nv for ; Mon, 23 Jan 2017 09:25:51 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0108.outbound.protection.outlook.com [104.47.37.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87D21295CE for ; Mon, 23 Jan 2017 09:25:50 -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=7TJfuGgWhxklN2KtIqhaRF1Vl8GjoeIgZmmIWBh8YKM=; b=ljDZZdGHuEX9uoB9s3OZPj+AUMacEMFyxluiT4I1UqT+Ue45G53TM3ov3THmajehf/DWbUFweeV3TIE1yZpOeUT1LG+2tZqKDqOTpjs8AfTX9sTKN+Jip5UAj6zM6JcA7rRIwE9J/AyF95V01lGSuhw4DTtAIUeD2vnh/D4Ot+k= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 17:25:49 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 17:25:49 +0000 From: Mike Bishop To: Patrick McManus , Alan Frindell Subject: RE: HPACK and Header sequence #s Thread-Topic: HPACK and Header sequence #s Thread-Index: AQHSdT8ZALNThsePbEukeY7zBgkn16FFpuIAgAAcyICAAI1Smg== Date: Mon, 23 Jan 2017 17:25:49 +0000 Message-ID: References: <243109C7-BC18-448C-8EE9-46E25F926D3A@fb.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:600:8300:3b9a:b84b:bb69:6212:230f] x-ms-office365-filtering-correlation-id: 2a1ddbcf-ea96-4520-02bf-08d443b4dfe4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:V0J0xr7Uf8nY/3BUuMqvvmiLDZn//kmpM5fjO4Ka1k1GTTKvgICjk4q2+uCQogMuO26ZxF3QpQ1WyM45KeJMgZkoAguVTlN2LqeSApEJHvzQSM5ULmhOUMdu3/HoDTiMEkJE+g0ll8i0P+qpNZ0S6K0Fi0EUsKX6n8VMtV8PDfIi7mel5kwy1nCv1Fg/mfKstnbV+jr8hiz3S4QrACj7Jk6GAvIInd0AD/kFQJHPsQzHB5KStydqN6g1HnF17khrlnzDlXp94bhK1oQWfiEsLG7J+9QyJiow6SZKeNc0IG3WucR3EE/9dRouMSNr/AEeQptbDwBQxdFZ3Pu4NHYsnEGb77MKF94zUmoMbvItbaAHo7oiKv32RFCIaneS3VxlCa65oBu16jB6iJL/9no8xhCSYacYylAAfnCKESzi78X4QVFdMjYQzEhN36UQkrSH+Wi2zYo51IOEN/NuMW1RqB8Z4p4EMIiDgeUvOm5GJrE= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39860400002)(39850400002)(39410400002)(39840400002)(24454002)(189002)(199003)(377454003)(6436002)(606005)(86362001)(99286003)(25786008)(6306002)(2950100002)(189998001)(106356001)(3280700002)(77096006)(81166006)(8676002)(54896002)(74316002)(5660300001)(6506006)(7736002)(5005710100001)(7906003)(2900100001)(4326007)(10290500002)(122556002)(8936002)(55016002)(54906002)(86612001)(2906002)(33656002)(9886003)(53936002)(50986999)(54356999)(76176999)(5001770100001)(3900700001)(97736004)(8990500004)(101416001)(10090500001)(68736007)(236005)(9686003)(92566002)(102836003)(6116002)(229853002)(7696004)(38730400001)(106116001)(105586002)(81156014)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708D8575670005494AEE1AF87720BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 17:25:49.4177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 17:25:52 -0000 --_000_BN6PR03MB2708D8575670005494AEE1AF87720BN6PR03MB2708namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes =96 the sequence numbers are a stopgap to keep HPACK working while we t= ransition away from -00=92s muxed-connection-on-stream-3. Sent from my Windows 10 phone From: Patrick McManus Sent: Monday, January 23, 2017 1:00 AM To: Alan Frindell Cc: Eric Rescorla; IETF QUIC WG Subject: Re: HPACK and Header sequence #s the assumption is we will move towards something like qpack https://tools.i= etf.org/html/draft-bishop-quic-http-and-qpack-01 On Mon, Jan 23, 2017 at 2:17 AM, Alan Frindell > wrote: > As I understand it, you are (effectively) requiring a single stream of > data for all the headers. It's not clear to me why it's useful in this > case to have the headers on distinct streams from each other as this > just seems like it introduces another opportunity for HOL blocking > that is harder to fix at the QUIC transport layer because it requires > a kind of smarts that is different from that to reduce HOL blocking > between packets on the same stream unless the transport either looks > into the frames or follows some heuristic about first in > first out... I agree. If QUIC is going to use HPACK, I would prefer all frames containi= ng header data to be on the connection control stream. --_000_BN6PR03MB2708D8575670005494AEE1AF87720BN6PR03MB2708namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Yes =96 the sequence numbers are a stopgap to keep H= PACK working while we transition away from -00=92s muxed-connection-on-stre= am-3.

 

Sent from my Windows 10 phone

 

From: Patrick McManus
Sent: Monday, January 23, 2017 1:00 AM
To: Alan Frindell
Cc: Eric Rescorla; IETF QUIC WG
Subject: Re: HPACK and Header sequence #s

 

the assumption is we will move towards something like qpac= k https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack-01


On Mon, Jan 23, 2017 at 2:17 AM, Alan Frindell <= span dir=3D"ltr"> <afrind@fb.com>= ; wrote:
>    As I understand it, you are (effectively= ) requiring a single stream of
>    data for all the headers. It's not clear to me why it's u= seful in this
>    case to have the headers on distinct streams from each ot= her as this
>    just seems like it introduces another opportunity for HOL= blocking
>    that is harder to fix at the QUIC transport layer because= it requires
>    a kind of smarts that is different from that to reduce HO= L blocking
>    between packets on the same stream unless the transport e= ither looks
>    into the frames or follows some heuristic about first in<= br> >    first out...

I agree.  If QUIC is going to use HPACK, I would prefer all fra= mes containing header data to be on the connection control stream.







--_000_BN6PR03MB2708D8575670005494AEE1AF87720BN6PR03MB2708namp_-- From nobody Mon Jan 23 14:56: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 B830712995A for ; Mon, 23 Jan 2017 14:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 Oja7NT_rTGN2 for ; Mon, 23 Jan 2017 14:56:13 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A741298A1 for ; Mon, 23 Jan 2017 14:56:13 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id v23so150954976qtb.0 for ; Mon, 23 Jan 2017 14:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cSdGuDGH6iWugEEaPvbUyiZWeQKKLtF/SwOKr26VXys=; b=scveuBhOQ8XUC8EuKSrXSuvrucY9v0mWbsN6P4lE3OMSbBgLwIRKAj2fBXdLEBV2gN W8C/hV2pByPWD8yZus1tcI+lxeonD+Y3LyNiSUBwP+q0ive4lai+oQll+oi8YP0ZLKxe FCNT4qNDZ9A6mrsAUuFOahQGNGPkHp9VFBb2GHqQAYungPnn6AGmKK1/ahP4+0CPDuzO QZ1PvEDZiddplhrz63sdGLOmycZ3zuCTNIpCOzijC54kvFXJUa82igdacUxDE6Yy2A/i Nryi1b4CxYDsMLSZLG8E8kp2LxyCPsAgbUnywxM9pWESMP2ruM7X6SduHJdUGUsieBgS IP1A== 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=cSdGuDGH6iWugEEaPvbUyiZWeQKKLtF/SwOKr26VXys=; b=Nx7g1bJ7dVRRbKmANZC8TZuqD4SjQm1bFDTJfg0Y+9HD7XaYmAioLdgh+qUJlKoeaS Si7aWk2hbRZBlFEFhfPTbN4zUgL5izVCqcbWArVyHSTtl23wj3X3k68poBzlkrqQtscU e9evUACyW/R0hPM4zJBPp5ZQFyZVhGGCeN/5yoHFHG3pz3bIrKdTIDjWUA5lPtwsp7bc +f145j3UKmb7Tv3MgbeQ+kT/bsL4eVAsT4CROtSa2deKUN2eC+vRNUnhzO7jIa23ZGtF uwTV+vM3HJTEA8tvb1FnY8M7e+9JgMCMDckdff5FnZX9CLksgnp/9F35kez9nNXe8Pzs RAKg== X-Gm-Message-State: AIkVDXKndnx4y912f0RHQLcJjV6S34lJshdKOCtbRWQsoI2hdkBoS9CQb/Njtvby4woXWIU4Ej8xQH7K4US4ccOf X-Received: by 10.200.40.38 with SMTP id 35mr25332175qtq.216.1485212172015; Mon, 23 Jan 2017 14:56:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.47.4 with HTTP; Mon, 23 Jan 2017 14:56:11 -0800 (PST) From: Victor Vasiliev Date: Mon, 23 Jan 2017 17:56:11 -0500 Message-ID: Subject: QUIC and security guarantees To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114136daee1c6d0546cae7c0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:56:15 -0000 --001a114136daee1c6d0546cae7c0 Content-Type: text/plain; charset=UTF-8 I've wanted to give my two cents on the TLS abstraction issue, but realized that it would be useful to first provide decide where we would have to draw the line if we draw it. Because of that, I've tried to compile a list of security guarantees and features we want the protocol to provide. Please tell me if I've missed something. (1) QUIC should provide confidentiality and authentication to all of its packets. (2) QUIC should have an ability to securely establish keys for (1) in-band, in a manner that at least works with TLS 1.3. (3) QUIC server should not send more than a limited amount of data to the peer until it has established that the peer can actually receive packets addressed to it. (4) QUIC should be able to support stateless rejects. (5) QUIC should authenticate the transport parameters, notably the QUIC version. (6) QUIC should provide a mechanism to refresh shared keys post-handshake (refresh for TLS tickets, source address tokens and traffic keys). Packet protection solves (1), but I will note that its layering level in the current documents is somewhat unclear: it lives in TLS binding document, but the document makes it sound TLS-independent. I think that making the packet protection level fixed for all variations of QUIC protocol is a reasonable plan. We currently defer (4) and (5) to TLS, and I will note that (3), the issue we currently solve with source address tokens (STKs), has interesting interactions with stateless rejects. We currently don't have a solid stateless reject mechanism spelled out in the documents, and I expect them to have a lot of subtle interactions with proof of source address (a notable edge case here is when the server cannot send the entire certificate in one flight because it's so big it becomes an amplification concern). Because of that, I suggest that we postpone the discussion of whether to put source address tokens into TLS layer until we have a plan for stateless rejects thought through. I've been having conversations with people about how one should work, and will be happy to present a mechanism with edge case analysis by the March meeting. -- Victor. --001a114136daee1c6d0546cae7c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've wanted to give my two cents on the TLS abstractio= n issue, but realized that it would be useful to first provide decide where= we would have to draw the line if we draw it.=C2=A0 Because of that, I'= ;ve tried to compile a list of security guarantees and features we want the= protocol to provide.=C2=A0 Please tell me if I've missed something.
(1) QUIC should provide confidentiality and authentication= to all of its packets.

(2) QUIC should have a= n ability to securely establish keys for (1) in-band, in a manner that at l= east works with TLS 1.3.

(3) QUIC server should no= t send more than a limited amount of data to the peer until it has establis= hed that the peer can actually receive packets addressed to it.
<= br>
(4) QUIC should be able to support stateless rejects.

(5) QUIC should authenticate the transport parameters, no= tably the QUIC version.

(6) QUIC should provide a = mechanism to refresh shared keys post-handshake (refresh for TLS tickets, s= ource address tokens and traffic keys).

Packet pro= tection solves (1), but I will note that its layering level in the current = documents is somewhat unclear: it lives in TLS binding document, but the do= cument makes it sound TLS-independent.=C2=A0 I think that making the packet= protection level fixed for all variations of QUIC protocol is a reasonable= plan.

We currently defer (4) and (5) to TLS, and = I will note that (3), the issue we currently solve with source address toke= ns (STKs), has interesting interactions with stateless rejects.=C2=A0 We cu= rrently don't have a solid stateless reject mechanism spelled out in th= e documents, and I expect them to have a lot of subtle interactions with pr= oof of source address (a notable edge case here is when the server cannot s= end the entire certificate in one flight because it's so big it becomes= an amplification concern).

Because of that, I sug= gest that we postpone the discussion of whether to put source address token= s into TLS layer until we have a plan for stateless rejects thought through= .=C2=A0 I've been having conversations with people about how one should= work, and will be happy to present a mechanism with edge case analysis by = the March meeting.

=C2=A0 -- Victor.
--001a114136daee1c6d0546cae7c0-- From nobody Mon Jan 23 15:26: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 7782D129400 for ; Mon, 23 Jan 2017 15:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.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 1KMMxgm8nDmO for ; Mon, 23 Jan 2017 15:26:12 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0099.outbound.protection.outlook.com [104.47.93.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990861293FD for ; Mon, 23 Jan 2017 15:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w3DU18K2v/Aub2f52T71e/4C2uq/rOjXI491hooqtek=; b=py3K4I6QPDPFYaCuiD9P4zz7K5M5Zfl9thAWM3yHFXkdAdn3Gh3gZfdmAqIVwfn15Gxi9+zzJMXOamz7qmlxKYwQ9U3LF6y6/PZbAkhxNPsnkBvrogxloG7/BMhi2KBOIKUeILqy9U1aWD0iLrtaybPhrlk96LgqOPBSGCril/E= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [192.168.1.3] (118.19.14.21) by TY1PR01MB0652.jpnprd01.prod.outlook.com (10.167.158.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 23:26:08 +0000 Subject: Re: Mapping QUIC version to that included in Alt-Svc header To: Mike Bishop , Julian Reschke , "Aron ." , IETF QUIC WG References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Tue, 24 Jan 2017 08:26:08 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [118.19.14.21] X-ClientProxiedBy: TY1PR01CA0146.jpnprd01.prod.outlook.com (10.174.224.150) To TY1PR01MB0652.jpnprd01.prod.outlook.com (10.167.158.15) X-MS-Office365-Filtering-Correlation-Id: d2648426-4c54-4876-5879-08d443e73618 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:TY1PR01MB0652; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 3:CHM/Kgonrl1hAxXrxPdqivyGrxYKvD18H3bbu/hRPQoJ1vBOiES9Gfd5CnXs4ZQqT0ie2Si0TeRGz4wES2WPNNQaIgdq1lNvQx91mSc3eA8uHLaLw0gkxcdaeFFYLqWPlf/Qq+amPFWyv8AW/+GoVq9CWFteUJZ9P1Wmgwdh6qWfaVdKVPNWMtVyLQKHK7wCmNMjx9Ig8pPrvF/a+xMpZrlYiY5fuVSp2p31GwWBkwPDn4gPYw56FJard+LtUXxkbl8YKsze9JxJ6jLfv2TgcQ==; 25:JAdAWOoAZSyeZ3gytyELU6EjRHV87mxBNcdyzFLb7vI29++lg1JGpuK7YbOz0Lrd5vEl8tKeWRSWrG+/QBZ9BY4py0rRW1Nz8GXWqh9JpZCOmsB2FHhfo2sAl5xA75v9BDbU0tkf8VOKsUzulUGFFVS+JANyq7tTiTVA59ulfC/LpbYx66YbrJ8Ig5dLNuHHMmxXfswfnGmBEjA4YAzN0HfOBEdG+EicNGgQ6ikOMUQRU3Kl2wh69bZneKae9tUnxEckqLA+VA10+DMVq4hDbxPZtiabfW4AWkSDMtKtYTcp9ahjL+c1uO3dCjcb+jol9dnfePh9F9a1gGw4U0ZQFlGNB1bfgVvAfXxOEq41OvHEhPrtYF7njhKWOtY0erE/LXI0sX8Uedie5GQ7pHF8vL1BvLqvUTocMNe5W7DG+AzYQS7h3ff65PWEEpPXS9HQRMjNFGmZxGK3iwEXS50DJg== X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 31:k4VNlizHlyqTY2BeB6HcTxUReJBt9EPWBEB4N/e89EBThWGJ77et0Qq5g0ZfV/O1qnBkfz/JMF8n7O1oZ3J1hIF04G2OF2s/vaEmbivXiPeij6LaR31wsjkG8Ob4ZDPcXKc6iGJsExPjUT/NxFh6l4W1821akYZJ+VVviNdLMuRHc6rFEcmHfl9yD5jF7HJLZixJ5Dm4OwMBzN9HV+i7iTVGifROC+8dwuoOc8AdRbdVvclgq0QVrG4ghhF/F5YGQB6dOrE7WSxw7p5eqJZfWEU2d7E2TzCUSPq9OmTknBc=; 4:qvz2Ri3PhJ5fDKBZEDCW/G6vKHX9pbwRbK1aifKnjTwacqPQxWtxGNJHf0SxWywpbG7DjkSeJtoqnglfQLeu/+xSCZ9SmYUmqJYjHOp/pgfwXPm9gM+8st5Ps/FF/Y8/G9UsEjW8GJJWyqaj7Jn1F3xHjT/FgvNKP+YcqGg+A+a+lfMP8HHtSpWzNN3CahOfdbkgokzlzvCKqmhgLaG082e/QkT2UX3ngcKxi4J0qoDolrhluucR/0+6l6offWbxszGgiVP/YdRiFtHwI+QgC6Rd4YH3aYmRZfD07RzE61jpTVRpiHrDVqCQ+TijSW7rhLcFqCq9Eo9avYb/RSHf8KOHb9WVcWKaZOYx0fHSMqhw/KfPGjMoSn1FLZXSyvQFgm2EcLb7Rq973ePvrlwuGh9o+IggWoZZvg08ceTRrEibuyupFMe0Cc6HTA6uaSgjYWFWhnhkrIO/tpv2RZyL4XqsdP0CiytuYhcJqpXk0S5m1ECruhxwsgm+Riuy1OV/IP8yyXwofAjGgr68v3aSXRyCAJDSFj2+ci+7BdnYXQpeAEQGcw7pv1yvWrk5HyDG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:TY1PR01MB0652; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0652; X-Forefront-PRVS: 0196A226D1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(199003)(24454002)(189002)(7736002)(4001350100001)(5001770100001)(66066001)(74482002)(25786008)(105586002)(106356001)(65956001)(47776003)(83506001)(65806001)(53936002)(1511001)(31696002)(50466002)(86362001)(97736004)(68736007)(2870700001)(101416001)(42882006)(2950100002)(229853002)(77096006)(6486002)(31686004)(42186005)(117156001)(92566002)(76176999)(50986999)(2906002)(38730400001)(39060400001)(54356999)(189998001)(65826007)(107886002)(3846002)(6116002)(23676002)(81156014)(81166006)(5660300001)(2421001)(8676002)(33646002)(90366009)(64126003)(305945005)(8666007)(2561002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0652; H:[192.168.1.3]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUyOzIzOldTcTZjdVAyYkhSV0U3TVY4aGZJdmFvV2wv?= =?utf-8?B?MWJSVjRKQ3V2MEUzcWVnNlFkMzRDQjlpcXpaTW1zNUhKQ1JORTZMbjg1aUJn?= =?utf-8?B?bGJRcDlDM3FIeGV4Z3p3WGN5cWxFeTJzVFVkM3p2UVhiaGxQK1dpNkJzeG1R?= =?utf-8?B?eHdXYW5wY0R5ZjNjNlpQT2dWTUt0V0ZRWUpPNnNSSG82UUUxTVdZeDJvSFla?= =?utf-8?B?Y1hHQlpqMys1d3hGa3lhWDArZmhFWnI2VjVtbFQ1ckc0R216d0JHOWxJOCtF?= =?utf-8?B?NWZtdmowaEYrRzMvVTY0Z1VJaXR0TERvMmxPT1MrbXh1YUxya3lsUTMwZTkx?= =?utf-8?B?YzFHR3RJWlRvaUk1SjlmNkhydEZaSUNBUFBlMUZ0eTdLdUpJd2Q5b3cza2pl?= =?utf-8?B?Y3pmdUJuUVl3cG9nWFBoaWRIS2FDdGVZa3RUcFRibnlnakp6RDI5cjZRSitE?= =?utf-8?B?UVhSQUJ3d2J3U1duZThtVXNUTXBvblAvWHhJcHIzTDFNZndSSFdKTlJkYmVE?= =?utf-8?B?ZkpCYkhkVDFHbVprR3ZrdGkrTXEyRVAzNThPMmRaOExrRkxEL0FxZUZRRVBj?= =?utf-8?B?bGZ5b0ZDdzNhZk85c1pZelliVXFIMm5HWXpIOU45bEJabnRuRVZIQVJjSWR1?= =?utf-8?B?SXFzblppMXcvVEZuNy9OMXZZSmt5Mit0UUF6NnFIanh6bTR4S3dkL29Yd3VI?= =?utf-8?B?Nko1RTlYbCtjNUV4MkRLN2N6OHlFaThzeTcvcTg3eXhYSU5tL1cvUDg2S0ZD?= =?utf-8?B?ZGFJekFZOFBZOWlRSURhd1QrYThMODd3RHpFb2I3MHhZc2JRalMwK2ZNUGRS?= =?utf-8?B?Nkx0VVQxNHN3L1VHbm91eTQ5My9McGJ2QU83bngwYmZUK21BVjhtdWdXdHlR?= =?utf-8?B?U3prZ3Z5K2VBTWpTSkZ0b1RzVGRwdnJrbkt3QkcvdldUUmhkRllPY0JaSVo4?= =?utf-8?B?SElJc0RrUldSUndDbmRmWi8yM285TkwwWWtPbW83U21MWVhSdVpUZnhqU2t5?= =?utf-8?B?c0dLRFFENUF3RnV6eUNSMFpmUWY5N2RvTWJ0ZUJyaTRTa0JHdUxJcHBBVUhV?= =?utf-8?B?T0ZMQTZ4MUgvZGdlUWNSWDZTMC9qdi9vTGRxdHg4K2NGL05zejVEc1VXQWh5?= =?utf-8?B?SmV3MEhnMUV2cldWNVRSSDlhcjF4ZEF0UGFPb25QWXlvSXk0Y2RFQkI0UFJm?= =?utf-8?B?WUZ6RGs5TWltQ3o1eHRWOU4rMnpUajRwamxraGR0enNjRzkrcXpZZmwwaEFx?= =?utf-8?B?RVMwZzVRNWVzWHNYK0o1Y0w4MU5MdWJMRjEzVFpmTnE1ZlNORElnZjN6a2tX?= =?utf-8?B?MEpVMlVvQ2dGdTdMT21tUmcyQjVnOW5nSkhmaGY3M0JBUm9hclVleEF0eWVk?= =?utf-8?B?d1VLS2toUmR4NEErR3c3N2ZmTGRBZzRScEhSQldxVTZqY3JINldTYnBxbVlI?= =?utf-8?B?YjhaMnB2NGJVeStzMEp1djNPWnNyNU4zL0c5LytuRWM0NkM5ejBnY0dKZnIy?= =?utf-8?B?THgzRjdoaTk0MXk2S094eVB5Y2FnSmszcEhzTzhPMmFSWEJkVHBQcG8rZmwr?= =?utf-8?B?QzVLVDRRUTZZK1pSQmFXUnlDcGVHSnVmTnRTN1lXNXAzK3BwRWJNVlNSOHJF?= =?utf-8?B?SkE5UkYxSjJZZC9hNmNxaWtPYjUrdklSUHNSdXZFeHBVdDRoQ2llRStobDAv?= =?utf-8?B?N0ljaVVjUFhnd0J3UkZrdVlBbk9MbzJhRVlPTGQ1WmZHdUZPSHN5SXUzZ1Nr?= =?utf-8?B?dkFOMFNmZENseTI1RHNwT2R0c3lUWno4b0lFNG1oNkdjVnBOdHYzb2hTRmF4?= =?utf-8?B?NUYxSzRSZ1RHU0tYZWtMaXN4WStCUS9IdW5SMzdhelhRUzNMS3B3UlJDZUYz?= =?utf-8?B?UDZFY3FaSmYvOHhYY3daU1FqbEVkSjBRWEhsNHB0Wkxmc0tVZ05CSS9zb0xw?= =?utf-8?B?VVMxOGN3V21tVGFybFdDMEc0K21VblAzVzYyczNPZzNRZkVvUGdwcjY1cWdV?= =?utf-8?Q?5QTlTB?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 6:9KC5UXEB+qynX1BnTBD73h5UnK9VZQrz9jz8wQhakIazuKbFo/eOXsnqRBM9oVEDndypCuOLADmxh6HIlqw2shEqEz0A+H/TY2leLemDuVeCG+3pcmklFQK56JBSx548/WmtrdSttdKe3pehYaEG1a6Ngl5wnQsiy2ICDcobSczwB1nMOhuCOvn0NzqrVRqeRbkg0RmLK5h8IK9cd1IvsdUTL0iX7WG0SuaaG4x7DNLK7qsSi9/NSfgvNkNjU+kFLkQbmbfBOkhgExBwtun0n1vazHNych/ct6o0hT9oGBsgnwYzF6MXxnzssmfGt6YxuHy3M0Btb9eNR+STq97UVzx4uBKDUdZ/iQ5tjHpsbvbxbPEB3Zj7qZn1xGiPlguHRzUmXcQbaoBgW3M8kt3LZRk8CegIzEb5ibYYQaA6Emo=; 5:3WIbZsWsGsjkUMZzUc052DozK1iXVVARp82Yse0gPphwWutBQPhZtHiR/g1TUNkjugzSl/hPnw7zRKk8SRa4Azp1z3bSwv7KE0vCs9E/6zmk/B6QQ5tBDmJ4h1zmwlEaa6gpeYv/a+8cRWdBcchz9Ru+uuxjHoIUyLEfhTTZ0G0=; 24:dmTa7cav2KZA4I/JbKqdfKDDHGO/RmjJpJJ5TC7WffxUBw5HBzIUg+04azhrUSXM8ZHmaHAZrnrmeTVxX080pAWPIsYU1JpcrTfijPhVlqQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 7:pFt+MrikQ9JX1durt76Bb6q9YYHONuZ2Lk+YZQclJyHQUVPnPeHV3B4daXfXn+2cOrquwVLjsekVh7Uvf6MmVvXBIRmQ8jrpQfdRE90x7BCcL6G+fSc2zIFI8LSyYv7o1Rv7HznIXIjcM+aHT8zZL0EgzmhbSkDTw1ENkJMssaP0NOKHSU4Oh6v0fy9gNQcHnfndkSJlOaUb2Wtmqrbh2bmvI4kKffI7waBxNUYajG9ZBzAz+5vYpNOvyG1BmpMOKroQZKd18FWsWgCW8xsStlIKUphve2M/BQsyMH/D1RYJUW7s8lV5gQCGYfXKZOjUmtmmXyC6AxmKJt2hCnwYQbwsnzc6V2NNQ9TJinxuo05YpQQE5C6kIuCtlIlDxpSDx46TosZAqytive2MeFDiJpcXoX3yoE63i853gB8x5fE4bD7rFsmVwjpOfm6UvcnhoZ2XwwlX4HlJvbaa7SmciQ== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2017 23:26:08.9343 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0652 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 23:26:14 -0000 On 2017/01/24 02:15, Mike Bishop wrote: > That (percent-encoded tokens) is what the original PR contained. Then Martin and Jana came out with a versioning scheme for QUIC where practically every commonly-used version would require percent-encoding all four bytes. So I added a straight hex option to compactly cover those cases. (Martin is arguing for hex-only, and let the existing pseudo-ASCII versions be the ones to suffer. He's also given the same don't-need-quotes feedback, and I’ll remove them in the next rev.) I haven't looked at the details, but this kind of stuff smells of overengineering from miles away, and very badly. Why can't we keep things simple? Regards, Martin. From nobody Mon Jan 23 23:29: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 32F4E129577 for ; Mon, 23 Jan 2017 23:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC6mmmvqrXfx for ; Mon, 23 Jan 2017 23:29:52 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c: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 306BA126CD8 for ; Mon, 23 Jan 2017 23:29:52 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id f73so40181729wmf.1 for ; Mon, 23 Jan 2017 23:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=00Ak/PpXyzGSiYEw7QcXLLzV9Vho/rqGZKl7ncYU7So=; b=T4nVroVMwCWeS82PP/I9a8RaflfUjCj4n5/yq7wKWnUOYLx64FHHCYiRZTRaRNWlE7 uOA6Z0vJ8U+MllgTZb5Gp/6vU4MZ3BX6hsrvddzvaY+TzjGPYYXQIqmrXuiUTI6iT0dk aJSECYlQvL92KbGQp/LKp1/GGj0snNCxstDWCEoDkHgS7gFiIN1YtfAq9xlM3fGfwoiJ y5I9bKTnaGSbh7J+9sovHe1umM2NinPZFyAf8A5wzp7obme5e5F7OoDeAYkz4bGH5FYa +ei5llvv1nM4nP1Uzqf4syZRvm+WgztrWCPBueLr3Pa6/IF+kCG1SMc0QCmMbTo+NYvV xjZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=00Ak/PpXyzGSiYEw7QcXLLzV9Vho/rqGZKl7ncYU7So=; b=Te9XpcPpSGuUIrOYgTDKEYRU3nQ33UWA8sq04+fewRBMohMaTFqk07PE8SznwCUx/J 485L5PR1O+mLDPGr3KFPBA2FzcqMkJ1Sov3EZj1vAv9eWJSUsYP9Q++BmfPYU16mCroB VsU7QaSxP0B4BORTkNkwmGuedAVko+VqL3HL/FLKgswoYogpZz7Uihjq0QzMyppHBpwX JabhIUi3ekW+hPUYVaqmrxgsNYnPth/o6rP3gJRBzg2AMQPiLiKZWyipfiDVCbOGIiM9 IBjlgXzD6+5YJ2H9WFTRaZJ1+HsuS6dqSVEmB4ke4CebNqV+KEeEuuXmykrjZYo+XNa9 MQqQ== X-Gm-Message-State: AIkVDXIzQ9GzJY9fhe4qPJLIynHY5c15NNrcgLHDyKpHwCxDb3kvvm0CL2PPo3XKIb9VrC0P X-Received: by 10.223.136.109 with SMTP id e42mr27075894wre.14.1485242990368; Mon, 23 Jan 2017 23:29:50 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:999c:254c:8548:1f46]) by smtp.gmail.com with ESMTPSA id 63sm24958374wmg.2.2017.01.23.23.29.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 23:29:49 -0800 (PST) From: marcelo bagnulo braun Subject: truncated packet numbers To: quic@ietf.org Message-ID: <841ffe81-886b-3939-a714-7c22820fdb45@it.uc3m.es> Date: Tue, 24 Jan 2017 08:29:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 07:29:55 -0000 Hi, I have a question about truncated packet numbers described in draft-ietf-quic-transport-01 I understand that while the packet sequence numbers cannot be reused in a single quic connection, the truncated packet sequence number carried in the quic header can wrap around and it is possible that two packets in the same connection carry the same value in the Packet number field, correct? If this is the case, then would it be possible the following situation? A quic endpoint is using let's say 8 bits for the packet number carried in the quic header. Because it cannot send more than 2^6 packets per RTT, the truncated packet sequence number can repeat after 4 RRTs. So suppose that the sender sends a packet with sequence number n and the packet is stored in some buffer along the path. The received deems the packet lost after a while. Now 4 RTTs later, the truncated packet number n is within the the packets that the receiver is expecting and the old packet is finally released from the buffer where it was held and delivered to the receiver. Would the receiver accept it as the new packet? Would any test detect that this is the old packet and not the new one? (the draft says that the full packet sequence number is used for the crypto operation, but i dont know if this means that it would be able to detect this situation or not). Thanks, marcelo From nobody Tue Jan 24 04:46: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 E7C0B129581 for ; Tue, 24 Jan 2017 04:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 Li2mYUvc9xHZ for ; Tue, 24 Jan 2017 04:46:48 -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 130D51294F8 for ; Tue, 24 Jan 2017 04:46:48 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u68so120254501ywg.0 for ; Tue, 24 Jan 2017 04:46:48 -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=j6N8DKfY7gLtIR9YjiUR/epjfite8c2iZtcDpjDh3Dg=; b=j54UmXiCTw3NPqPrDUJEO0PwUznx73P5iWTCIHPPqmTojuvx5ZXYF5SQs41HQN9ayQ iyz7CeiSzZqwS/lzMKO53agLT3MVwfoTLV7lar49R7PSk0DQVKgz2m5GS7PTtZ7HDNmH Lsk8jp4FiD4BLYmiX/XQ65qPZlTaXeTBQyuA2TLPUul8yF6Dk3oMeJ74ZFxpINb/4Ea9 U29ccEdtfoRgk5QCrP6w3tNWuqRVYEVN61rZH6PRuWc9z2Eb1nDiJylTB8UjERmbJElw O8txyDHUBpRsz1rY/FmtKBK9KG1ZNpcYWCROyeAzLxl6FoxbPlYaIygtzY8NuCO9/G5w 7LZA== 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=j6N8DKfY7gLtIR9YjiUR/epjfite8c2iZtcDpjDh3Dg=; b=Wd7cug0btD2bt4UAyeo7Y0HCUN3cMvdQWnyPNhH8LHlb3yi7Cp+AgPdZ7P0jFydt3h IslnjQLAHzETjlCTQvfekH2jO6Wchs3cIdCoXRKohbYqNefldGpA7YRVXNe79UlEvs0d COyxnKP2JkUCBTpzllm6QpeQ/OXcYfRXSRaJPQlg4SOHhLffpC/ILMAYFQXyJdrlf3LY vNLFMhCxDrY3daGX5uqseA5LMUm0MQiYiJqLcVP1QebKfJArLHL9s7Efo4QpGF6dyctD V2qIbzMVJuxL4Q8Q8uvXe3RLRLrsHELMjUNNcqJGVUdoyqeGsHvL1sg62Zv4vLI+YBUc zFlg== X-Gm-Message-State: AIkVDXJCH+cpDW7PanfnXgnVr6+8dnC5FaQc7LPu9YZTHIkgWCagD+M5/HNI/BE4Mo9wcYhJvbi7FzjfdAgAHJAC X-Received: by 10.129.82.212 with SMTP id g203mr25622843ywb.107.1485262007202; Tue, 24 Jan 2017 04:46:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Tue, 24 Jan 2017 04:46:26 -0800 (PST) In-Reply-To: <841ffe81-886b-3939-a714-7c22820fdb45@it.uc3m.es> References: <841ffe81-886b-3939-a714-7c22820fdb45@it.uc3m.es> From: Ian Swett Date: Tue, 24 Jan 2017 07:46:26 -0500 Message-ID: Subject: Re: truncated packet numbers To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=94eb2c07a1ee5703ef0546d682f9 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 12:46:50 -0000 --94eb2c07a1ee5703ef0546d682f9 Content-Type: text/plain; charset=UTF-8 In this situation, the receiver would attempt to decrypt with the larger packet number, that would fail, and it would be dropped. On Tue, Jan 24, 2017 at 2:29 AM, marcelo bagnulo braun wrote: > Hi, > > I have a question about truncated packet numbers described in > draft-ietf-quic-transport-01 > > I understand that while the packet sequence numbers cannot be reused in a > single quic connection, the truncated packet sequence number carried in the > quic header can wrap around and it is possible that two packets in the same > connection carry the same value in the Packet number field, correct? > > If this is the case, then would it be possible the following situation? > > A quic endpoint is using let's say 8 bits for the packet number carried in > the quic header. Because it cannot send more than 2^6 packets per RTT, the > truncated packet sequence number can repeat after 4 RRTs. > > So suppose that the sender sends a packet with sequence number n and the > packet is stored in some buffer along the path. The received deems the > packet lost after a while. Now 4 RTTs later, the truncated packet number n > is within the the packets that the receiver is expecting and the old packet > is finally released from the buffer where it was held and delivered to the > receiver. Would the receiver accept it as the new packet? Would any test > detect that this is the old packet and not the new one? (the draft says > that the full packet sequence number is used for the crypto operation, but > i dont know if this means that it would be able to detect this situation or > not). > > Thanks, marcelo > > --94eb2c07a1ee5703ef0546d682f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In this situation, the receiver would attempt to decrypt w= ith the larger packet number, that would fail, and it would be dropped.
On Tue, Jan 24, 2017 = at 2:29 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrot= e:
Hi,

I have a question about truncated packet numbers described in draft-ietf-qu= ic-transport-01

I understand that while the packet sequence numbers cannot be reused in a s= ingle quic connection, the truncated packet sequence number carried in the = quic header can wrap around and it is possible that two packets in the same= connection carry the same value in the Packet number field, correct?

If this is the case, then would it be possible the following situation?

A quic endpoint is using let's say 8 bits for the packet number carried= in the quic header. Because it cannot send more than 2^6 packets per RTT, = the truncated packet sequence number can repeat after 4 RRTs.

So suppose that the sender sends a packet with sequence number n and the pa= cket is stored in some buffer along the path. The received deems the packet= lost after a while. Now 4 RTTs later, the truncated packet number n is wit= hin the the packets that the receiver is expecting and the old packet is fi= nally released from the buffer where it was held and delivered to the recei= ver. Would the receiver accept it as the new packet? Would any test detect = that this is the old packet and not the new one? (the draft says that the f= ull packet sequence number is used for the crypto operation, but i dont kno= w if this means that it would be able to detect this situation or not).

Thanks, marcelo


--94eb2c07a1ee5703ef0546d682f9-- From nobody Tue Jan 24 17:07: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 234FA1295F1 for ; Tue, 24 Jan 2017 17:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EEU0AY2hNTv0 for ; Tue, 24 Jan 2017 17:07:02 -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 A49791295E8 for ; Tue, 24 Jan 2017 17:07:02 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u68so2624924ywg.0 for ; Tue, 24 Jan 2017 17:07:02 -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=kpxt2+gfvCYMuf1/a/R40NtprJQu/MpxLx8NTLFMcaw=; b=MTtkIlYW1VfO/vKEAPq8eAZo5e+C69TiPCsaJYdsYkzL/Y4UbAxXDKhBvZVGaWaYH1 dB5lj1+Fa+ZpZEzhkCwvKqXiNClpYuwMtQtC1QWp7H1Y4gASM8DmQ7kVr7Ul6sqeGHDA LySY01cY4pJqVFImBOzW16zN/5LhIHSlweTfaiXrlSFkaYGcnnJvjo0sz3tszVFMio8l bbnbGMi7KRjG2zquuXZS1f+MwPzte8JgYJWCkb/L9wUm6v2ap3dg3a/NqJJ5fUYu0XPN 2XEkdKcnaff6mesuqgVyqPpSxPieQNiTlrBsDA9v+TQ3+mHknE/nQhNpNkzIGffRwjH+ vhMA== 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=kpxt2+gfvCYMuf1/a/R40NtprJQu/MpxLx8NTLFMcaw=; b=GXSUI67oN22PwRWyp7RkByRC2UdlSjFJ8OT4Lqdz0K0jN7oniOpJe3cMT2s5L7sHHI U1WSbp4xI71h33sS7GjpPsjibwYjxj+flZC2Ki8CBpXGMgch6oV3+XVp4+4qmGbnYCjT G6UWZ0oEZgZxR7UWk3Z8pL4Yhqae8VDKJv6FsmKWDN7frEISMfxt4q7LDJ1Mr44tfI5Z w7kYAlCQL1N6ER6faWSfXR16Zr77f6vEXw7/wWHqNZhYSwYGGyAoHEvI9TLg/BKlbEkZ RsFbgsllShMbUOpH8uiAN2dG3bgNGV4p1gcTJzRZBUc6BCNiSjpOyp16sAUqtIdUpsMW CH2A== X-Gm-Message-State: AIkVDXLln7ih/5M1IVPHy+GRacWQCUsB0de6LsLEJSi00w0OmwWbpX6tJ71NjaUdDJ2sx8N5RezfItasrNheiw== X-Received: by 10.129.125.84 with SMTP id y81mr27668458ywc.120.1485306421666; Tue, 24 Jan 2017 17:07:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 24 Jan 2017 17:06:21 -0800 (PST) From: Eric Rescorla Date: Wed, 25 Jan 2017 10:06:21 +0900 Message-ID: Subject: Encrypting more of the packet header. To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114928baa5e2c00546e0d9d9 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 01:07:04 -0000 --001a114928baa5e2c00546e0d9d9 Content-Type: text/plain; charset=UTF-8 TL;DR. Encrypt the packet number with ECB or something like it. This is probably a bad idea but I wanted to write it down. I had an idea last night about encrypting the packet number. Here's a diagram of a QUIC regular packet: +-+-+-+-+-+-+-+-+ | Flags (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + [Connection ID (64)] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Version (32)] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (8/16/32/48) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | {Encrypted Payload (*)} ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The insight here is that the reason that the packet number is outside of the encryption is because it is used as the nonce for the AEAD function. However, there are encryption algorithms (which we usually avoid for various reasons) which do not need a nonce. Specifically, what we could do is derive two keys: K_h: header encryption K_p: packet encryption So you get: +-+-+-+-+-+-+-+-+ | Flags (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + [Connection ID (64)] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Version (32)] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | {Packet Number (8/16/32/48)} ... | encrypted with K_h +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | {Encrypted Payload (*)} ... ^ | | encrypted with K_p +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v This of course leaves the question of which crypto mode you use to encrypt the packet number. The natural choice is ECB, but that only works with data values the same size as the cipher block, which for AES is much bigger than the packet number (128 bits). So, that's waste, though you might of course add stuff to the block if we had other headers. We could use 3DES (which has a 64-bit block) or FFX (which can be used with any block size, but at some additional computational cost). Two pre-emptive responses to common questions: 1. Yes, ECB and FFX are not generally as good as AEAD algorithms, in particular because they don't have integrity and they reveal patterns in the plaintext. However, this is data which would (a) otherwise be in the clear and (b) is folded into the ordinary AEAD integrity check. 2. As long as we correctly generate K_h and K_p independently using a KDF, then any weaknesses in K_h don't implicate K_p. Again, this probably isn't worth doing with the current amount of stuff in the headers, but I wanted to write it down so that people. -Ekr --001a114928baa5e2c00546e0d9d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TL;DR. Encrypt the packet number with ECB or somethin= g like it. This
is probably a bad idea but I wanted to write it d= own.

I had an idea last night about encrypting the= packet number. Here's
a diagram of a QUIC regular packet:

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2= =A0| =C2=A0 Flags (8) =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= div>=C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Connection ID (64)] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Version (32)] =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =C2=A0
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Packet Number (8/16/32/48) =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{Encrypte= d Payload (*)} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0
The insight here is = that the reason that the packet number is outside
of the encrypti= on is because it is used as the nonce for the AEAD
function. Howe= ver, there are encryption algorithms (which we usually
avoid for = various reasons) which do not need a nonce. Specifically,
what we= could do is derive two keys:

=C2=A0 K_h: header e= ncryption
=C2=A0 K_p: packet encryption

=
So you get:

=C2=A0 =C2=A0+-+-+-+-+-= +-+-+-+
=C2=A0 =C2=A0| =C2=A0 Flags (8) =C2=A0 |
=C2=A0= =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Connection ID (64)] =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Version (32= )] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^=C2=A0
=C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {Packet Number (8/16/32/48)} = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... | encrypted with= K_h
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+ v
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{Encrypted Payload (*)} =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... ^
=C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | encrypted with K_p
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v

This of course leaves the question of which crypto mode you us= e to encrypt
the packet number. The natural choice is ECB, but th= at only works with
data values the same size as the cipher block,= which for AES is much
bigger than the packet number (128 bits). = So, that's waste, though you
might of course add stuff to the= block if we had other headers.
We could use 3DES (which has a 64= -bit block) or FFX (which can be used
with any block size, but at= some additional computational cost).

Two pre-empt= ive responses to common questions:

1. Yes, ECB and= FFX are not generally as good as AEAD algorithms, in
particular = because they don't have integrity and they reveal patterns
in= the plaintext. However, this is data which would (a) otherwise be in the
clear and (b) is folded into the ordinary AEAD integrity check.

2. As long as we correctly generate K_h and K_p inde= pendently using
a KDF, then any weaknesses in K_h don't impli= cate K_p.

Again, this probably isn't worth doi= ng with the current amount of
stuff in the headers, but I wanted = to write it down so that people.

-Ekr
--001a114928baa5e2c00546e0d9d9-- From nobody Tue Jan 24 18:44: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 AA33812962D for ; Tue, 24 Jan 2017 18:44:50 -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 xY_8TQlur-nX for ; Tue, 24 Jan 2017 18:44:49 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5589712962B for ; Tue, 24 Jan 2017 18:44:49 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s140so62353192qke.0 for ; Tue, 24 Jan 2017 18:44:49 -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=W/BFXRDoIoicQeMh3yf1X3O6woTzDk6UqB2mkcJDNvM=; b=HuloI0cKREtDMuGFv+7OQhduF7jrNc7wnjuFO5e4FqQgTN9Zq5OkSH7evQZThzalKv P+o5Tfa/Rz+b3QV/YQMyiQC7wNxrLpNsP5dcMfD2xTK+HkV9dC+xwwtRNtq5INajM3I+ cfqIXBYhmUVHRPU/9oIMBjIQ7PLBA6A70b+TQfL7w+UA3vv56//PdEcWeOwYMbGt57hk u/L6ajXMhXO64+iG3Nhv7cX9NbSn0LT4MB5TehSSAz7ebKyGWFQc5v4KjgL4rHTB2pbX haI7Ty1XmDiLdDa87IKa3PLZOm41Bdk6SLMFkPxXT85/X80HeJmmArWZeGcrvsmL+g50 PkTQ== 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=W/BFXRDoIoicQeMh3yf1X3O6woTzDk6UqB2mkcJDNvM=; b=LQHMgQyzsTqTWDCyRq/B8EROatQpPG6W60Py4fOSEenmzsONjSqUYFWMV3EQDg728J w6dTIcFesbVEsFR3YT7+vg1xGU94kfJPzVSYBX2b/lzd0mRbIK6j7RDkX+d8CDJseO+Q aoCB806e31qW5bTnFF0ji5OFPT5j3q6+2qpcP8ddwI3uj6mw/DGmxItppqKPJYam6ggh C7/GT4fjBj4brH5oSpwi9klK/5YRW6JgKoTcB/Tc1+gGKwhuR97ygM9Tr/9RxpphdC34 sGDLINN5kCF5ysmWRW2lF6yAmTHl1N2qLtaYcD7tlAIV5zmyNn/LSnhEczVnLQIxyKxZ AC7w== X-Gm-Message-State: AIkVDXJwQwQeGcLpGKBFahxVxSfCw7sVaDIka/U4rAbpL4CxNbkU0KNtyQ6aYHhuuNw3lTVXdZn038X3L/bNfw== X-Received: by 10.233.216.68 with SMTP id u65mr27254793qkf.68.1485312288270; Tue, 24 Jan 2017 18:44:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 24 Jan 2017 18:44:47 -0800 (PST) From: Martin Thomson Date: Wed, 25 Jan 2017 11:44:47 +0900 Message-ID: Subject: QPACK insert abuse To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 02:44:50 -0000 What prevents someone from inserting values at index 2^31? From nobody Tue Jan 24 19:44: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 1732112967E for ; Tue, 24 Jan 2017 19:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssRgOQXRYaKR for ; Tue, 24 Jan 2017 19:44:53 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0105.outbound.protection.outlook.com [104.47.41.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878E7129670 for ; Tue, 24 Jan 2017 19:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mMAbNTkCAZLFMviNB5aA/EXp9Os93e65fAHSTyo5hQQ=; b=QRoSxX3KGLWWtW72UoTmYuLhpj8H20qyGs5IGKoeqzEGl6meNzh6sebmnGEf3g9xzdKvVIdg6OAoQHwQBGiepdSdMjep880Pbmq2Y/GxBPa9Ya7/ZtHDFL90gkad9XcDE49M5snKpBy3w1d9J23+NW6rjis3ISsFOxWsveKSMqc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 25 Jan 2017 03:44:50 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.021; Wed, 25 Jan 2017 03:44:50 +0000 From: Mike Bishop To: Martin Thomson , IETF QUIC WG Subject: RE: QPACK insert abuse Thread-Topic: QPACK insert abuse Thread-Index: AQHSdrUDqBHEBu/Zrkq4l4liEhdN5KFIjS9A Date: Wed, 25 Jan 2017 03:44:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:b439:5a59:7004:f73e] x-ms-office365-filtering-correlation-id: f73fdd24-7faf-473f-048d-08d444d48451 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:DNNCsVNVL9uSaLTAjzdwhyH/WlRsoEFuSdoDuhTYc5aT7Kzzrfm2XVkfCnK4wrY46sCuOho6Aftuv9e/MnL6ChsZreFF2HSNZPCYGWDzoKBv65yebHT6ZMgcX13Agbw10m+I/EUShgyeTNB97c5DxshIiDy9dEcF1B5PKkZxMLY7wZumMWraXrrdET3XFsFD9GtHhbhC3HpIDYSdF+44PTPLqFZGKlRG4ST/D2uyNeSJzA9rq9xglobAEMTneG6oy2BW9TxiCjZ64uSOJtjh7ynhM3z9I3dJtT/Co/6ZAucXfPj31DIo1o1gXObDJjv1cLYJB7fvNCfCNQ64lD890GNW0Ssj4to0H5lb3Y9XlNb2BBGBqC10XJG4iek+AJTFsR+7UTI4oi0VdlV7K3cbuYJMDM3bcliIAhrs/WVgXSF3hs9MNYOkyDbjy24ZvJNHlF3+y7XGeW35fhEvnx+BymuLcztAjDsgmpiCFqBRYcg= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(6047074); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(377454003)(199003)(13464003)(189002)(97736004)(77096006)(8676002)(39060400001)(81156014)(2900100001)(38730400001)(5001770100001)(7116003)(189998001)(3280700002)(122556002)(68736007)(81166006)(229853002)(92566002)(7736002)(86362001)(6506006)(3480700004)(107886002)(8936002)(53936002)(3660700001)(86612001)(305945005)(101416001)(102836003)(50986999)(7696004)(6116002)(74316002)(6436002)(55016002)(33656002)(99286003)(2950100002)(9686003)(105586002)(2906002)(5005710100001)(10290500002)(8990500004)(10090500001)(106356001)(5660300001)(76176999)(106116001)(54356999)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2017 03:44:50.6147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Jan 2017 03:44:55 -0000 Q3VycmVudGx5LCBub3RoaW5nLiAgVGhpcyBnb2VzIGJhY2sgdG8geW91ciBwcmV2aW91cyBzdWdn ZXN0aW9uIHRvIGhhdmUgYSBtYXhpbXVtIHZhbGlkIGluZGV4Lg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI0LCAyMDE3 IDY6NDUgUE0NClRvOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBRUEFD SyBpbnNlcnQgYWJ1c2UNCg0KV2hhdCBwcmV2ZW50cyBzb21lb25lIGZyb20gaW5zZXJ0aW5nIHZh bHVlcyBhdCBpbmRleCAyXjMxPw0KDQo= From nobody Tue Jan 24 21:23: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 5DBAC12973E for ; Tue, 24 Jan 2017 21:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWzbgFB_tOOF for ; Tue, 24 Jan 2017 21:23:08 -0800 (PST) Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.76]) (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 50F0512962F for ; Tue, 24 Jan 2017 21:23:08 -0800 (PST) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1485321786; x=1486531386; bh=TRN8oNpzDWkZg22PDmDIPj93xXeGhMifMVTwFrpnAZk=; b=xpWv+q/4FvINMAO5qtqizs3BO/p nBXrA1uvrSkYHpNksxs/3tnCi1r9L/GcHijl2YIlSzk+3RXWZG4vhbGc59S4Y0VrldmbOb/0mEdU6 rkYWeNZ2dCGXKvJrvXUEoRQEFGz3aizvZiBR3ogiOGkjIoDSzz/cIVUFGM4hUGvd9nJbtfvQSoJLN 8gbV3pk//ktSALEhsWZ2KCfaH09I1Ah06Aj1nyVxvthR7C8B5Pt1lxiBAn/cAHa3xI8T2LsKXStQF sJKs0KvKJGtjhWhEvNJHlMmfAgkogwaNgTpbG0Ko/Y86EplAY/WJVLHSkpw6CicoFncyCuKlnCcio AspZGTw==; Received: by omgo.iij.ad.jp (mo900) id v0P5N6FS029062; Wed, 25 Jan 2017 14:23:06 +0900 X-MXL-Hash: 5888363a088c305d-c60bf9702e3e8762272d4d2bc6d250529d374455 Date: Wed, 25 Jan 2017 14:23:05 +0900 (JST) Message-Id: <20170125.142305.39232901203171730.kazu@iij.ad.jp> To: quic@ietf.org Subject: ack for insertion in QPACK From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 05:23:09 -0000 Hi, What will happen if we change the currect QPACK as follows: - Insertions also require acks. - An encoder can use acked-indces only. - If a non-acked entry exists for a name-value, the encoder encodes the entire of name-value without using its index. Does this make QPACK HoL-free? --Kazu From nobody Tue Jan 24 21:32: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 6E01C1297B8 for ; Tue, 24 Jan 2017 21:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mdd3QKwCSIaz for ; Tue, 24 Jan 2017 21:32:53 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 02EFC12978C for ; Tue, 24 Jan 2017 21:32:52 -0800 (PST) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 4C23B3A021 for ; Wed, 25 Jan 2017 00:32:52 -0500 (EST) Received: by mail-qk0-f173.google.com with SMTP id u25so64643209qki.2 for ; Tue, 24 Jan 2017 21:32:52 -0800 (PST) X-Gm-Message-State: AIkVDXKIz6UTLZZjV3+qc+y/BfCrw18jzmwhajJRyE8NpIYZQ9i8hQV4OjH/M4ZBW+Hdyz9mcyZ6/06jP7uYWg== X-Received: by 10.55.43.158 with SMTP id r30mr36363154qkr.28.1485322372093; Tue, 24 Jan 2017 21:32:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Tue, 24 Jan 2017 21:32:51 -0800 (PST) In-Reply-To: <20170125.142305.39232901203171730.kazu@iij.ad.jp> References: <20170125.142305.39232901203171730.kazu@iij.ad.jp> From: Patrick McManus Date: Wed, 25 Jan 2017 14:32:51 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ack for insertion in QPACK To: Kazu Yamamoto Content-Type: multipart/alternative; boundary=001a1149430e5da4e30546e490db Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 05:32:55 -0000 --001a1149430e5da4e30546e490db Content-Type: text/plain; charset=UTF-8 certainly an implementation could choose your algorithm.. but a primary use case (and benefit) of HPACK is sending O(100) requests in the first round trip - and that scheme would defeat that (via cwnd).. requests tend to come in batches and removing the redundancy in the batch without rtt is a useful property. On Wed, Jan 25, 2017 at 2:23 PM, Kazu Yamamoto wrote: > Hi, > > What will happen if we change the currect QPACK as follows: > > - Insertions also require acks. > - An encoder can use acked-indces only. > - If a non-acked entry exists for a name-value, the encoder > encodes the entire of name-value without using its index. > > Does this make QPACK HoL-free? > > --Kazu > > --001a1149430e5da4e30546e490db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
certainly an implementation could choose your algorithm.. = but a primary use case (and benefit) of HPACK is sending O(100) requests in= the first round trip - and that scheme would defeat that (via cwnd).. requ= ests tend to come in batches and removing the redundancy in the batch witho= ut rtt is a useful property.

On Wed, Jan 25, 2017 at 2:23 PM, Kazu Yamamoto <kazu@iij= .ad.jp> wrote:
Hi,

What will happen if we change the currect QPACK as follows:

- Insertions also require acks.
- An encoder can use acked-indces only.
- If a non-acked entry exists for a name-value, the encoder
=C2=A0 encodes the entire of name-value without using its index.

Does this make QPACK HoL-free?

--Kazu


--001a1149430e5da4e30546e490db-- From nobody Wed Jan 25 00:48:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC0129889 for ; Wed, 25 Jan 2017 00:48:05 -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 TZUoHcDsradr for ; Wed, 25 Jan 2017 00:48:04 -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 CAEF6129864 for ; Wed, 25 Jan 2017 00:48:04 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 65so146955296otq.2 for ; Wed, 25 Jan 2017 00:48:04 -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=612SoMloFEsY07JGvcT3A8zPHaq65yPEClc42rRQdLM=; b=rVveu1pEhPt3Et99CCXAkeaEUiZ5dQrxL4cVYFJSIGjKn5boXzAf4u3ypX37uXzDvi Aky+fUXCxYYqefnNalzims1LT6DcePYGxCkGwGyK2t8PrMl42MKUU5GC2PnHJ3sLNmqw cF4aiTWFdl1G3ATQ/U0V0s0sNKfBb6Uu1QhhM7in6uEmWnPeIZD2D905rhCtRmn68uii /wPQqaWwrvz6rkIwpXFDFOLdPU9FqpFlkR912Sd6CY4OH2SIYlQsbGwygqsgV/SkwPFU jTx/5A+nNfWj9b/nlCCYMk628tf0oWbBJTzkj1SsAZEE8fzSPv49Dp2+0s7tqwxOq3CB h/MQ== 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=612SoMloFEsY07JGvcT3A8zPHaq65yPEClc42rRQdLM=; b=AMWC6/vXmnDrpvRXDhJbK9ezqT6gCUkq4tnJc/Eafv+p+tIVHZX/0dLwCA4/vLnLXP 1JWfuavqkr5Z17CZUUtUlhCoO4Jxi+5JJFG7ciFBajWlRNlvSVfi37T+OPi3LkA8UC+C OgBOu89zZ603xDK5oFk1TlozHQ4MwNid/YFEfGG1mfVqfzbJwh1B3zeycz4UWB4dWg87 I3iiZnuUPkW5dDNpzyf8KBrdwBDtL5zCtMOvpsNLdg214+kMufZg8+5YKuM/zmQKDfLZ HDsvYBRxDGGIdljLxrifCIkn/0XSdtlLKohswPvpZaJBXlsVLuAUpD2vKcvv2MQ7DaLI P4Xg== X-Gm-Message-State: AIkVDXIzHB0vJNmXcZB52kf8hz6GoAm2hyPRyGaVJ52+pl+6e2oSpGVTwQtT6PM18wphvtH/FHwIc+2Sl2u7Cg== X-Received: by 10.157.35.26 with SMTP id j26mr18212720otb.135.1485334084124; Wed, 25 Jan 2017 00:48:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.113 with HTTP; Wed, 25 Jan 2017 00:48:03 -0800 (PST) From: Kazuho Oku Date: Wed, 25 Jan 2017 17:48:03 +0900 Message-ID: Subject: re when and how to change Connection ID (and who should generate) To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 08:48:06 -0000 >From what I see, there are two types of network address changes; one that can be detected by an endpoint (e.g. network interface up) and one that cannot be detected (NAT rebind). For those that can be detected, we should change the connection ID. For those that cannot be detected, what we could do the most is periodically change the connection ID. Regarding how we change connection ID, there are two methods. One is to register the next connection ID prior to switching between the IDs. In this case, after establishing a QUIC connection you would immediately register the next ID over the encrypted channel. It would be analogous to how we send NewSessionTicket in TLS 1.3. The other method is to send a packet marked by the new ID that contains the old ID. Considering the fact that in some server-side deployments there would be load balancers that route incoming packets based on connection IDs, it would be beneficial to choose the first approach, since you would have some time on the server side to have the mapping for the new ID registered to the load balancer. In the latter approach, the binding between the IDs cannot be found until you decrypt the packet, but it is unlikely for a load balancer to be able to decrypt all the packets. And considering this, it would be beneficial if the first connection ID and the next connection IDs are generated on the server-side (in that case, the first connection ID will be assigned to the client at the point of the TLS handshake and the next connection ID will be sent along the session ticket), since in case of rebinding from Wifi to cellular network (or vice-versa) there is an non-negligible chance that packets will start arriving at a different POP (of CDN deployments). For example, when I am at Kyoto (500km from Tokyo) using Wifi, a POP located in Osaka (50km from Kyoto) will likely be used as a destination (thanks to anycast). But once I get switched to a cellular network, I will going though a L3 gateway located in Tokyo, and therefore my packets will start arriving at a POP in Tokyo. In such case, we'd still want to continue sending responses (at least for those already in-flight, we would send GOAWAY so that new requests would come through a new connection). It seems to me that using server-generated connection ID (with the ID of the POP) would be the most concise option. -- Kazuho Oku From nobody Wed Jan 25 01:05: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 7CC2D129889 for ; Wed, 25 Jan 2017 01:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEQ1nTziE85D for ; Wed, 25 Jan 2017 01:05:24 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E813412984C for ; Wed, 25 Jan 2017 01:05:23 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id c206so18832534wme.0 for ; Wed, 25 Jan 2017 01:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=pHre9z2mckn/X9MFa7OF/q2ztULkVqzIxH5y5pK3+t0=; b=oIqAY6R3msdhsSCIaWwDjW7lHEp/wqNc45IE6DLPXHB+AaDV1+rM++vZIEZ3meDdVl of/Z7KBUHh6OrLhcXfaLua7UCxMM7y4p6MSQglmzDzGCZ0mZalnaak+GG4JkCrL2l/7Y beNMmKXtDj68oy0OJTXreh12c/RXM9JZNKulvHmoXUxNsNHYIbMkPTjYKEP2bNo7DzKM MCdy6koZkozRStPiz7521lmXkOaaEs6RrO3BX9qdy51sPC4QyJCf5kkXIb+EKtgtL6H/ 0AvtjJ2N14Mypo8lMFnK0QlcwtkmGe41BlFqwZM1FeSXmZmkADhIfGIbL3l9PPEK/xBV gt+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pHre9z2mckn/X9MFa7OF/q2ztULkVqzIxH5y5pK3+t0=; b=fTPyJkp0kASmEJt8bEZ7oj+ZKKIxS+qP+y1uhdDW1rvoknB58Y+bC1llrS0ezxRVEH B5p/PKDchse5tfWoQd7OXV7qkHNduvuaYHMmJSTS+QptIpqFoGYBuVBsE82kMOcnYp/n OnAePUNhRzlIuFh6F+ro9A8Bk3mP839GeRvkvsc5V4KCMuF3boDFzWBTSl90j+UHBTm1 YWNR/gHd4wAHNM19J+ZlvNMKoqfDe6juf0qMURIAAGzBFgMXYmdjhHPV5NxwBiIKvSuq Au0w+9DOBMdR3TSXrBAKVIoFJFySz4/LYuk1DgJgcgGns0+CnoRfIfe4WnLXGwmJtHH1 CvXg== X-Gm-Message-State: AIkVDXIG3TUJoEWVyHHwAqjfvw6vcINhPZSssAWElYp+AoWr3L7G8+Iy/eLKPE++P+fZX158 X-Received: by 10.28.67.134 with SMTP id q128mr20583335wma.34.1485335122103; Wed, 25 Jan 2017 01:05:22 -0800 (PST) Received: from Macintosh-6.local (213.167.16.95.dynamic.jazztel.es. [95.16.167.213]) by smtp.gmail.com with ESMTPSA id k43sm23885927wrc.46.2017.01.25.01.05.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 01:05:21 -0800 (PST) Subject: Re: re when and how to change Connection ID (and who should generate) To: quic@ietf.org References: From: marcelo bagnulo braun Message-ID: Date: Wed, 25 Jan 2017 10:05:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Jan 2017 09:05:26 -0000 Sorry if i missed this, but why do you want to change the connection id udring the lifetime of a connection? El 25/01/17 a las 09:48, Kazuho Oku escribió: > >From what I see, there are two types of network address changes; one > that can be detected by an endpoint (e.g. network interface up) and > one that cannot be detected (NAT rebind). > > For those that can be detected, we should change the connection ID. > For those that cannot be detected, what we could do the most is > periodically change the connection ID. > > Regarding how we change connection ID, there are two methods. > > One is to register the next connection ID prior to switching between > the IDs. In this case, after establishing a QUIC connection you would > immediately register the next ID over the encrypted channel. It would > be analogous to how we send NewSessionTicket in TLS 1.3. > > The other method is to send a packet marked by the new ID that > contains the old ID. > > Considering the fact that in some server-side deployments there would > be load balancers that route incoming packets based on connection IDs, > it would be beneficial to choose the first approach, since you would > have some time on the server side to have the mapping for the new ID > registered to the load balancer. In the latter approach, the binding > between the IDs cannot be found until you decrypt the packet, but it > is unlikely for a load balancer to be able to decrypt all the packets. > > And considering this, it would be beneficial if the first connection > ID and the next connection IDs are generated on the server-side (in > that case, the first connection ID will be assigned to the client at > the point of the TLS handshake and the next connection ID will be sent > along the session ticket), since in case of rebinding from Wifi to > cellular network (or vice-versa) there is an non-negligible chance > that packets will start arriving at a different POP (of CDN > deployments). > > For example, when I am at Kyoto (500km from Tokyo) using Wifi, a POP > located in Osaka (50km from Kyoto) will likely be used as a > destination (thanks to anycast). But once I get switched to a cellular > network, I will going though a L3 gateway located in Tokyo, and > therefore my packets will start arriving at a POP in Tokyo. > > In such case, we'd still want to continue sending responses (at least > for those already in-flight, we would send GOAWAY so that new requests > would come through a new connection). It seems to me that using > server-generated connection ID (with the ID of the POP) would be the > most concise option. > From nobody Wed Jan 25 01:07: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 0CC7912984C for ; Wed, 25 Jan 2017 01:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsX6623BJGLQ for ; Wed, 25 Jan 2017 01:07:23 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0107.outbound.protection.outlook.com [104.47.33.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12AE129889 for ; Wed, 25 Jan 2017 01:07:22 -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=/+hxqFu0VIKltjolT0AsEW4jYqQhaggAaUCJnVkgbRw=; b=S09B4oGoJDYhE818ObbdAefOYcCcf9wR3bvoZBjBbSATx9yBXXeWnwTn06aPTXGTdoxieLp8xWA1EfyvslDRZEmbagkWrHfr2zdggml6tMhcUEofnTtUA1Vl6bIGflpljxtHiAbYuGHH/PmSVbzmLyLjLXMpAk47/HZDZuyt1kc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 25 Jan 2017 09:07:21 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.021; Wed, 25 Jan 2017 09:07:21 +0000 From: Mike Bishop To: Patrick McManus , Kazu Yamamoto Subject: RE: ack for insertion in QPACK Thread-Topic: ack for insertion in QPACK Thread-Index: AQHSdsshGLNNtE0G/UyAPKFHYNwBLaFIq1qAgAA7ZiA= Date: Wed, 25 Jan 2017 09:07:21 +0000 Message-ID: References: <20170125.142305.39232901203171730.kazu@iij.ad.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:b439:5a59:7004:f73e] x-ms-office365-filtering-correlation-id: 8228ca2b-066b-4c97-f22f-08d445019202 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:K/kDXpFS78wKB1VFjWXmYUqmuHi13ESm6OLJhgQ3OzxMv5XFZLP1t6GPQTjw//cXjD+y7tO6GDAYcZmMMiR2GhxCDtkjpH7vp5iTqMDtyimUEXYUwZwnU57Yj75aUrlbTr8Bjxonluds0H7u714fEC5UEaYQhrMCR3Heej9TfBbYemeMDZx4olKwMoS93pp3T22prADHovwoVnpjjVOj8jV05OEQ5rVR/D8mwcGi7smVC2qOyhmYskAjsjYTuHoNVGtZPYHdh4UhbW6EIuzBngDJuZhdzAI7cC+9aqhr6AwE1vUFCbTF08A7Gu/agw0Rz6ec9NQ/ipRCBBvnLpe2pu5xyzWhLkF875+/mqwj/bv1ewnowgR1a6jeIWzTpALl/Gm2oP4HpKwTcgt03rWkVzTEDxXG9vNdx0XLthai9K41cHYSjXxhD+dkj42MAl7pM+4hMDfIe6lUuGUIibJIuOK/ppMczqKDhPiOwScpwWQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123558021)(20161123560025)(20161123555025)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(377454003)(189002)(24454002)(199003)(561944003)(6506006)(105586002)(6436002)(25786008)(6306002)(9686003)(10290500002)(77096006)(33656002)(106356001)(99286003)(7736002)(106116001)(38730400001)(229853002)(55016002)(68736007)(74316002)(122556002)(101416001)(5005710100001)(81156014)(8676002)(8990500004)(5660300001)(19609705001)(81166006)(54896002)(102836003)(189998001)(2950100002)(86362001)(3660700001)(2900100001)(790700001)(50986999)(2906002)(92566002)(6116002)(5001770100001)(53936002)(54356999)(7696004)(97736004)(76176999)(236005)(10090500001)(86612001)(8936002)(4326007)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270854130346C75F37FE600487740BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2017 09:07:21.0500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 09:07:25 -0000 --_000_BN6PR03MB270854130346C75F37FE600487740BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgZXNzZW50aWFsbHkgd2hhdCBCdWNr4oCZcyBwcm9wb3NhbCBib2lscyBkb3duIHRv LCBJIHRoaW5rIOKAkyB5b3UgY2FuIGluc2VydCwgYnV0IHlvdSBjYW7igJl0IHJlZmVyZW5jZSB1 bnRpbCB5b3Uga25vdyBpdOKAmXMgYmVlbiBzZWVuLiAgQSBwcmV2aW91cyB2ZXJzaW9uIG9mIFFQ QUNLIGFsc28gaGFkIGFja3Mgb24gaW5zZXJ0cywgYnV0IHRoYXQgbWVhbnQgZG91YmxlIHRoZSBh Y2staGFuZGxpbmcgbG9naWMuICAoQW5kIEkgZGlkbuKAmXQgYmxvY2sgcmVmZXJlbmNlcyBiZWZv cmUgdGhlIGFjaywgc2luY2UgdGhhdOKAmXMgc29tZXRoaW5nIGFuIGVuY29kZXIgY2FuIGNob29z ZSB0byBkbyBvciBub3QsIHRyYWRpbmcgb2ZmIGxhY2stb2YtSE9MQiB2ZXJzdXMgY29tcHJlc3Np b24gZWZmaWNpZW5jeS4pDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBQYXRyaWNrIE1jTWFudXMNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkg MjQsIDIwMTcgOTozMyBQTQ0KVG86IEthenUgWWFtYW1vdG8gPGthenVAaWlqLmFkLmpwPg0KQ2M6 IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBhY2sgZm9yIGluc2Vy dGlvbiBpbiBRUEFDSw0KDQpjZXJ0YWlubHkgYW4gaW1wbGVtZW50YXRpb24gY291bGQgY2hvb3Nl IHlvdXIgYWxnb3JpdGhtLi4gYnV0IGEgcHJpbWFyeSB1c2UgY2FzZSAoYW5kIGJlbmVmaXQpIG9m IEhQQUNLIGlzIHNlbmRpbmcgTygxMDApIHJlcXVlc3RzIGluIHRoZSBmaXJzdCByb3VuZCB0cmlw IC0gYW5kIHRoYXQgc2NoZW1lIHdvdWxkIGRlZmVhdCB0aGF0ICh2aWEgY3duZCkuLiByZXF1ZXN0 cyB0ZW5kIHRvIGNvbWUgaW4gYmF0Y2hlcyBhbmQgcmVtb3ZpbmcgdGhlIHJlZHVuZGFuY3kgaW4g dGhlIGJhdGNoIHdpdGhvdXQgcnR0IGlzIGEgdXNlZnVsIHByb3BlcnR5Lg0KDQpPbiBXZWQsIEph biAyNSwgMjAxNyBhdCAyOjIzIFBNLCBLYXp1IFlhbWFtb3RvIDxrYXp1QGlpai5hZC5qcDxtYWls dG86a2F6dUBpaWouYWQuanA+PiB3cm90ZToNCkhpLA0KDQpXaGF0IHdpbGwgaGFwcGVuIGlmIHdl IGNoYW5nZSB0aGUgY3VycmVjdCBRUEFDSyBhcyBmb2xsb3dzOg0KDQotIEluc2VydGlvbnMgYWxz byByZXF1aXJlIGFja3MuDQotIEFuIGVuY29kZXIgY2FuIHVzZSBhY2tlZC1pbmRjZXMgb25seS4N Ci0gSWYgYSBub24tYWNrZWQgZW50cnkgZXhpc3RzIGZvciBhIG5hbWUtdmFsdWUsIHRoZSBlbmNv ZGVyDQogIGVuY29kZXMgdGhlIGVudGlyZSBvZiBuYW1lLXZhbHVlIHdpdGhvdXQgdXNpbmcgaXRz IGluZGV4Lg0KDQpEb2VzIHRoaXMgbWFrZSBRUEFDSyBIb0wtZnJlZT8NCg0KLS1LYXp1DQoNCg== --_000_BN6PR03MB270854130346C75F37FE600487740BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGF04oCZcyBlc3NlbnRpYWxseSB3aGF0IEJ1Y2vigJlzIHByb3Bvc2FsIGJvaWxzIGRv d24gdG8sIEkgdGhpbmsg4oCTIHlvdSBjYW4gaW5zZXJ0LCBidXQgeW91IGNhbuKAmXQgcmVmZXJl bmNlIHVudGlsIHlvdSBrbm93IGl04oCZcyBiZWVuIHNlZW4uJm5ic3A7IEEgcHJldmlvdXMgdmVy c2lvbiBvZiBRUEFDSyBhbHNvIGhhZA0KIGFja3Mgb24gaW5zZXJ0cywgYnV0IHRoYXQgbWVhbnQg ZG91YmxlIHRoZSBhY2staGFuZGxpbmcgbG9naWMuJm5ic3A7IChBbmQgSSBkaWRu4oCZdCBibG9j ayByZWZlcmVuY2VzIGJlZm9yZSB0aGUgYWNrLCBzaW5jZSB0aGF04oCZcyBzb21ldGhpbmcgYW4g ZW5jb2RlciBjYW4gY2hvb3NlIHRvIGRvIG9yIG5vdCwgdHJhZGluZyBvZmYgbGFjay1vZi1IT0xC IHZlcnN1cyBjb21wcmVzc2lvbiBlZmZpY2llbmN5Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBhdHJpY2sgTWNNYW51czxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDI0LCAyMDE3IDk6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IEth enUgWWFtYW1vdG8gJmx0O2thenVAaWlqLmFkLmpwJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBR VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogYWNr IGZvciBpbnNlcnRpb24gaW4gUVBBQ0s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5jZXJ0YWlubHkgYW4gaW1wbGVtZW50YXRpb24gY291bGQgY2hvb3NlIHlvdXIgYWxnb3Jp dGhtLi4gYnV0IGEgcHJpbWFyeSB1c2UgY2FzZSAoYW5kIGJlbmVmaXQpIG9mIEhQQUNLIGlzIHNl bmRpbmcgTygxMDApIHJlcXVlc3RzIGluIHRoZSBmaXJzdCByb3VuZCB0cmlwIC0gYW5kIHRoYXQg c2NoZW1lIHdvdWxkIGRlZmVhdCB0aGF0ICh2aWEgY3duZCkuLiByZXF1ZXN0cyB0ZW5kIHRvIGNv bWUgaW4gYmF0Y2hlcw0KIGFuZCByZW1vdmluZyB0aGUgcmVkdW5kYW5jeSBpbiB0aGUgYmF0Y2gg d2l0aG91dCBydHQgaXMgYSB1c2VmdWwgcHJvcGVydHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyNSwgMjAxNyBhdCAyOjIzIFBNLCBL YXp1IFlhbWFtb3RvICZsdDs8YSBocmVmPSJtYWlsdG86a2F6dUBpaWouYWQuanAiIHRhcmdldD0i X2JsYW5rIj5rYXp1QGlpai5hZC5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SGksPGJyPg0KPGJyPg0KV2hhdCB3aWxsIGhhcHBlbiBpZiB3ZSBjaGFuZ2UgdGhlIGN1cnJl Y3QgUVBBQ0sgYXMgZm9sbG93czo8YnI+DQo8YnI+DQotIEluc2VydGlvbnMgYWxzbyByZXF1aXJl IGFja3MuPGJyPg0KLSBBbiBlbmNvZGVyIGNhbiB1c2UgYWNrZWQtaW5kY2VzIG9ubHkuPGJyPg0K LSBJZiBhIG5vbi1hY2tlZCBlbnRyeSBleGlzdHMgZm9yIGEgbmFtZS12YWx1ZSwgdGhlIGVuY29k ZXI8YnI+DQombmJzcDsgZW5jb2RlcyB0aGUgZW50aXJlIG9mIG5hbWUtdmFsdWUgd2l0aG91dCB1 c2luZyBpdHMgaW5kZXguPGJyPg0KPGJyPg0KRG9lcyB0aGlzIG1ha2UgUVBBQ0sgSG9MLWZyZWU/ PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2Vu emIiPi0tS2F6dTwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB270854130346C75F37FE600487740BN6PR03MB2708namp_-- From nobody Wed Jan 25 05:32: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 D1F571298C5 for ; Wed, 25 Jan 2017 05:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 K0SkYY5JBebx for ; Wed, 25 Jan 2017 05:32:44 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 1661B1298C1 for ; Wed, 25 Jan 2017 05:32:44 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id x49so19417830qtc.2 for ; Wed, 25 Jan 2017 05:32: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=vGj3wRBudJQm8U16XxsbSJb1OCybuq0EcmE9OyMMkCA=; b=Mo78nl3vhxDHMSYcatPRnDKvwb/065oAj8mqUZybwjv3sZgM6bSDjseYpKDtTK3ZiR RInQUrn1HPZVFxVG/hJ8MQvM0vxMZC7HgQqq3OWD31hQ6sxMKI8KqyAbxWQFhZCh9ayC WOVbpLa8A+31UMKFYcjJ5ErwLpdxIkCIeLY1LzZxA5AtQtAryVm3/9YQk2OiB4kQXP9Y qIAboZyFNDQU38HKRjwppVdEzUb2n2paA6mUDTs+9KYtdLIHXjuI2o0owQZvvKkWZAMn mMYSwVNEEnYA4mQKsQBx4a97qSKjOX7oap6VsNT+ZLLD2HLeZJUlQ+IlFwGo4GaLRHwe P6Fw== 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=vGj3wRBudJQm8U16XxsbSJb1OCybuq0EcmE9OyMMkCA=; b=IC5A6OpXVBp2wJnDNMYdnIxA3V6b62HQCkDfPkqO8UXKwnhbGC5kWa4Qp05sI/1XXh /0t+2JdLfzXedzToERQ0EdteS5NqdElbzuP2QnXk+M2dVzoM2DNjoIiPVL7L51gzxhBd uZQMI0iY3hWb4wIC4JMsczF1fmY0N5xR+DRsCRJQ9qqRK5J9O5IyGCblsHb4doOGpL/V 67h54NxA9eSfX7vEQHlHBm+ctef0VjoSZ8CNUzEEB4vNq6SVtnZfo73thzyGHOvjkfDG fUUiE4GK8IuvPyoiqVgWuyBd5z41Uv+TC5B0FfCEjl2WT6100QIL+q8vWyc9adEqpF2o Vd/A== X-Gm-Message-State: AIkVDXIQ1wFZv/NFVzKuK/8sn8vveDsExQnwrztVfKi9Hf6hq+IDVy55B3+nbUATPckuaOOOlDglRinxF4C5Pg== X-Received: by 10.237.35.84 with SMTP id i20mr36298803qtc.247.1485351162885; Wed, 25 Jan 2017 05:32:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 25 Jan 2017 05:32:42 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 25 Jan 2017 22:32:42 +0900 Message-ID: Subject: Re: re when and how to change Connection ID (and who should generate) To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 13:32:46 -0000 There was a link to this document in the agenda: https://docs.google.com/document/d/16vHie4Qe44-SKZzxNzL4cClbCKqO7P3B-DYEAFR= gWGs In short, the current design of this feature - the ability to continue a connection after one or other peer changes its point of network attachment - creates a new way to track activity across those different points of network attachment. For example, if I continue a connection from WiFi to cellular as I leave my house, my two different ISPs for those uplinks (which where I live is often the same entity) can match the two connections up and track me as I come and go. On 25 January 2017 at 18:05, marcelo bagnulo braun wro= te: > Sorry if i missed this, but why do you want to change the connection id > udring the lifetime of a connection? > > > El 25/01/17 a las 09:48, Kazuho Oku escribi=C3=B3: > >> >From what I see, there are two types of network address changes; one >> that can be detected by an endpoint (e.g. network interface up) and >> one that cannot be detected (NAT rebind). >> >> For those that can be detected, we should change the connection ID. >> For those that cannot be detected, what we could do the most is >> periodically change the connection ID. >> >> Regarding how we change connection ID, there are two methods. >> >> One is to register the next connection ID prior to switching between >> the IDs. In this case, after establishing a QUIC connection you would >> immediately register the next ID over the encrypted channel. It would >> be analogous to how we send NewSessionTicket in TLS 1.3. >> >> The other method is to send a packet marked by the new ID that >> contains the old ID. >> >> Considering the fact that in some server-side deployments there would >> be load balancers that route incoming packets based on connection IDs, >> it would be beneficial to choose the first approach, since you would >> have some time on the server side to have the mapping for the new ID >> registered to the load balancer. In the latter approach, the binding >> between the IDs cannot be found until you decrypt the packet, but it >> is unlikely for a load balancer to be able to decrypt all the packets. >> >> And considering this, it would be beneficial if the first connection >> ID and the next connection IDs are generated on the server-side (in >> that case, the first connection ID will be assigned to the client at >> the point of the TLS handshake and the next connection ID will be sent >> along the session ticket), since in case of rebinding from Wifi to >> cellular network (or vice-versa) there is an non-negligible chance >> that packets will start arriving at a different POP (of CDN >> deployments). >> >> For example, when I am at Kyoto (500km from Tokyo) using Wifi, a POP >> located in Osaka (50km from Kyoto) will likely be used as a >> destination (thanks to anycast). But once I get switched to a cellular >> network, I will going though a L3 gateway located in Tokyo, and >> therefore my packets will start arriving at a POP in Tokyo. >> >> In such case, we'd still want to continue sending responses (at least >> for those already in-flight, we would send GOAWAY so that new requests >> would come through a new connection). It seems to me that using >> server-generated connection ID (with the ID of the POP) would be the >> most concise option. >> > From nobody Wed Jan 25 19:07: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 39205129430 for ; Wed, 25 Jan 2017 19:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA2exIEpP1YS for ; Wed, 25 Jan 2017 19:07:19 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id AF5CF129449 for ; Wed, 25 Jan 2017 19:07:19 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D96404334CA; Thu, 26 Jan 2017 03:07:18 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C27154334C9; Thu, 26 Jan 2017 03:07:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1485400038; bh=3zJzZoSBb9FK9altXxyeXOoR1UpRRcsSng+LsST/UYo=; l=23862; h=From:To:CC:Date:References:In-Reply-To:From; b=cz4U+LbF00hwXHgYyEozsGlq9IOLoeWuVvedPWZoVzuU5zRDsUaDi9ven4zXgeUZ1 X6pzNS/hVYusGZlA+Cup6cyb3Q0YVmzM4UY0KO34tUkayuNs5/CR3pRIUnYnaSyqDC 0W7bpVXzlUSVJtTC2nmqQmXbumvKmoEkKlV8d4nk= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BD3C41FC86; Thu, 26 Jan 2017 03:07:18 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 25 Jan 2017 19:07:12 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Wed, 25 Jan 2017 22:07:12 -0500 From: "Lubashev, Igor" To: Mike Bishop , Patrick McManus , Kazu Yamamoto , Martin Thomson Subject: RE: ack for insertion in QPACK Thread-Topic: ack for insertion in QPACK Thread-Index: AQHSdssg5FehPqqpnEqLsTy6laZVnKFI/yuAgAA774CAANjXYA== Date: Thu, 26 Jan 2017 03:07:11 +0000 Message-ID: <64484f337f934b4b879fc40e0143921f@usma1ex-dag1mb5.msg.corp.akamai.com> References: <20170125.142305.39232901203171730.kazu@iij.ad.jp> 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.237.15] Content-Type: multipart/alternative; boundary="_000_64484f337f934b4b879fc40e0143921fusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 03:07:21 -0000 --_000_64484f337f934b4b879fc40e0143921fusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0IHRoaXMgYWxnb3JpdGhtPw0KDQo9PT0gQ2hhbmdlcyB0byBIVFRQIEFwcCA9PT0N Cg0KT3BlbiBhIHNpbmdsZSBzdHJlYW0gZm9yIGVhY2ggR0VUL1BPU1QvSEVBRC/igKYgKGNsaWVu dCBzdHJlYW0pIG9yIFBVU0ggKHNlcnZlciBzdHJlYW0pLiAgTm8gc2VwYXJhdGlvbiBmb3IgaGVh ZGVycyBhbmQgYm9keS4NCg0KQmVuZWZpdHM6IHNpbXBsaWZpY2F0aW9uIG9mIEhUVFAgbW9kZWwg KGp1c3Qgb25lIHN0cmVhbSkgYW5kIG5vIG5lZWQgdG8gcmVhZCB1bm5lZWRlZCBoZWFkZXJzIChI VFRQIGFwcCBjYW4ganVzdCByZXNldCB0aGUgc3RyZWFtcyBpdCBkb2VzIG5vdCBuZWVkKS4NCg0K DQo9PT0gQ2hhbmdlcyB0byBRUEFDSyBzdWJzeXN0ZW0gPT09DQoNCkluc3RlYWQgb2YgdHJhY2tp bmcgdXNlIGNvdW50IHBlciBkeW5hbWljIHRhYmxlIGluZGV4LCBRUEFDSyBlbmNvZGVyIGlzIHRv IHRyYWNrIHN0cmVhbXMgdGhhdCB1c2VkIHRoaXMgaW5kZXguDQpJbiBwYXJ0aWN1bGFyLCB0cmFj ayB0d28gYml0bWFwcyBwZXIgaW5kZXg6DQoNCsK3ICAgICAgICAgc3RyZWFtcyB0aGF0IHVzZWQg dGhlIGluZGV4IG9ubHkgaW4gdGhlIGluaXRpYWwgaGVhZGVycyAoaW5pdGlhbF9zdHJlYW1zKSwg YW5kDQoNCsK3ICAgICAgICAgc3RyZWFtcyB0aGF0IHVzZWQgdGhlIGluZGV4IGluIHRyYWlsZXIg aGVhZGVycyAoYW5kIHBvc3NpYmx5IGluIHRoZSBpbml0aWFsIHN0cmVhbXMpOiAodHJhaWxlcl9z dHJlYW1zKQ0KUGVyaW9kaWNhbGx5LCBjbGVhciBiaXRzIG9mIGZyb20gdGhlIGJpdG1hcHMgYXMg c3RyZWFtcyBhcmUgY2xvc2VkLg0KDQpXaGVuIGEgUVBBQ0sgZW5jb2RlciB3aXNoZXMgdG8gREVM RVRFIGEgc3RyZWFtLCBpdCBzZW5kcyBhIERlbGV0ZV9SZXF1ZXN0KGluZGV4LCBpbml0aWFsX3N0 cmVhbXMsIHRyYWlsZXJfc3RyZWFtcykgb24gdGhlIENvbnRyb2wgQ2hhbm5lbCAoMykuDQoNClRo ZSBRUEFDSyBkZWNvZGVyIChyZWNlaXZlciBvZiB0aGlzIERlbGV0ZV9SZXF1ZXN0KSB3aWxsIGV4 ZWN1dGUgdGhlIOKAnGRlbGV0ZeKAnSBhbmQgc2VuZCBEZWxldGVBY2soaW5kZXgpIHRvIHRoZSBD b250cm9sIENoYW5uZWwgKDMpLCB3aGVuOg0KDQrCtyAgICAgICAgIEFsbCBpbml0aWFsX3N0cmVh bXMgaGF2ZSByZWFkIHRoZWlyIGluaXRpYWwgaGVhZGVycyAob3IgcmVzZXQgYmVmb3JlIHRoYXQp LCBhbmQNCg0KwrcgICAgICAgICBBbGwgdHJhaWxlcl9zdHJlYW1zIGhhdmUgY2xvc2VkIChpLmUu IHJlYWQgdGhlaXIgdHJhaWxlciBoZWFkZXJzIG9yIHJlc2V0IGJlZm9yZSB0aGF0KS4NCg0KVXBv biB0aGUgcmVjZWlwdCBvZiB0aGUgRGVsZXRlQWNrIG1lc3NhZ2UsIFFQQUNLIGVuY29kZXIgaXMg ZnJlZSB0byByZXVzZSB0aGUgaW5kZXguDQoNCg0KLSAgICAgICAgICBJZ29yDQoNCg0KDQoNCg0K RnJvbTogTWlrZSBCaXNob3AgW21haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tXQ0K U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDE3IDY6MDcgUE0NClRvOiBQYXRyaWNrIE1j TWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPjsgS2F6dSBZYW1hbW90byA8a2F6dUBpaWouYWQu anA+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IGFjayBm b3IgaW5zZXJ0aW9uIGluIFFQQUNLDQoNClRoYXTigJlzIGVzc2VudGlhbGx5IHdoYXQgQnVja+KA mXMgcHJvcG9zYWwgYm9pbHMgZG93biB0bywgSSB0aGluayDigJMgeW91IGNhbiBpbnNlcnQsIGJ1 dCB5b3UgY2Fu4oCZdCByZWZlcmVuY2UgdW50aWwgeW91IGtub3cgaXTigJlzIGJlZW4gc2Vlbi4g IEEgcHJldmlvdXMgdmVyc2lvbiBvZiBRUEFDSyBhbHNvIGhhZCBhY2tzIG9uIGluc2VydHMsIGJ1 dCB0aGF0IG1lYW50IGRvdWJsZSB0aGUgYWNrLWhhbmRsaW5nIGxvZ2ljLiAgKEFuZCBJIGRpZG7i gJl0IGJsb2NrIHJlZmVyZW5jZXMgYmVmb3JlIHRoZSBhY2ssIHNpbmNlIHRoYXTigJlzIHNvbWV0 aGluZyBhbiBlbmNvZGVyIGNhbiBjaG9vc2UgdG8gZG8gb3Igbm90LCB0cmFkaW5nIG9mZiBsYWNr LW9mLUhPTEIgdmVyc3VzIGNvbXByZXNzaW9uIGVmZmljaWVuY3kuKQ0KDQpGcm9tOiBRVUlDIFtt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF0cmljayBNY01hbnVz DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI0LCAyMDE3IDk6MzMgUE0NClRvOiBLYXp1IFlhbWFt b3RvIDxrYXp1QGlpai5hZC5qcDxtYWlsdG86a2F6dUBpaWouYWQuanA+Pg0KQ2M6IElFVEYgUVVJ QyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTog YWNrIGZvciBpbnNlcnRpb24gaW4gUVBBQ0sNCg0KY2VydGFpbmx5IGFuIGltcGxlbWVudGF0aW9u IGNvdWxkIGNob29zZSB5b3VyIGFsZ29yaXRobS4uIGJ1dCBhIHByaW1hcnkgdXNlIGNhc2UgKGFu ZCBiZW5lZml0KSBvZiBIUEFDSyBpcyBzZW5kaW5nIE8oMTAwKSByZXF1ZXN0cyBpbiB0aGUgZmly c3Qgcm91bmQgdHJpcCAtIGFuZCB0aGF0IHNjaGVtZSB3b3VsZCBkZWZlYXQgdGhhdCAodmlhIGN3 bmQpLi4gcmVxdWVzdHMgdGVuZCB0byBjb21lIGluIGJhdGNoZXMgYW5kIHJlbW92aW5nIHRoZSBy ZWR1bmRhbmN5IGluIHRoZSBiYXRjaCB3aXRob3V0IHJ0dCBpcyBhIHVzZWZ1bCBwcm9wZXJ0eS4N Cg0KT24gV2VkLCBKYW4gMjUsIDIwMTcgYXQgMjoyMyBQTSwgS2F6dSBZYW1hbW90byA8a2F6dUBp aWouYWQuanA8bWFpbHRvOmthenVAaWlqLmFkLmpwPj4gd3JvdGU6DQpIaSwNCg0KV2hhdCB3aWxs IGhhcHBlbiBpZiB3ZSBjaGFuZ2UgdGhlIGN1cnJlY3QgUVBBQ0sgYXMgZm9sbG93czoNCg0KLSBJ bnNlcnRpb25zIGFsc28gcmVxdWlyZSBhY2tzLg0KLSBBbiBlbmNvZGVyIGNhbiB1c2UgYWNrZWQt aW5kY2VzIG9ubHkuDQotIElmIGEgbm9uLWFja2VkIGVudHJ5IGV4aXN0cyBmb3IgYSBuYW1lLXZh bHVlLCB0aGUgZW5jb2Rlcg0KICBlbmNvZGVzIHRoZSBlbnRpcmUgb2YgbmFtZS12YWx1ZSB3aXRo b3V0IHVzaW5nIGl0cyBpbmRleC4NCg0KRG9lcyB0aGlzIG1ha2UgUVBBQ0sgSG9MLWZyZWU/DQoN Ci0tS2F6dQ0KDQo= --_000_64484f337f934b4b879fc40e0143921fusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5ODMyMjExNzsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg0NDQ1NzA0MCAt NjQ1NjUzODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDoxNTg5NTM5Njc4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxNjgwMDExODQ2IDk0NDY1OTExMiA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhvdyBhYm91dCB0aGlzIGFsZ29yaXRobT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PSBDaGFuZ2Vz IHRvIEhUVFAgQXBwID09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PcGVuIGEgc2luZ2xlIHN0 cmVhbSBmb3IgZWFjaCBHRVQvUE9TVC9IRUFEL+KApiAoY2xpZW50IHN0cmVhbSkgb3IgUFVTSCAo c2VydmVyIHN0cmVhbSkuJm5ic3A7IE5vIHNlcGFyYXRpb24gZm9yIGhlYWRlcnMgYW5kIGJvZHku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbmVmaXRzOiBzaW1wbGlmaWNhdGlvbiBvZiBIVFRQ IG1vZGVsIChqdXN0IG9uZSBzdHJlYW0pIGFuZCBubyBuZWVkIHRvIHJlYWQgdW5uZWVkZWQgaGVh ZGVycyAoSFRUUCBhcHAgY2FuIGp1c3QgcmVzZXQgdGhlIHN0cmVhbXMgaXQgZG9lcyBub3QgbmVl ZCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PT09IENoYW5nZXMgdG8gUVBBQ0sgc3Vic3lzdGVtID09PTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbnN0ZWFkIG9mIHRyYWNraW5nIHVzZSBjb3VudCBwZXIgZHluYW1p YyB0YWJsZSBpbmRleCwgUVBBQ0sgZW5jb2RlciBpcyB0byB0cmFjayBzdHJlYW1zIHRoYXQgdXNl ZCB0aGlzIGluZGV4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcGFy dGljdWxhciwgdHJhY2sgdHdvIGJpdG1hcHMgcGVyIGluZGV4OjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5zdHJlYW1zIHRoYXQgdXNlZCB0aGUgaW5kZXggb25seSBpbiB0aGUgaW5pdGlh bCBoZWFkZXJzIChpbml0aWFsX3N0cmVhbXMpLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwx IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+c3RyZWFtcyB0aGF0IHVzZWQgdGhlIGluZGV4IGluIHRyYWlsZXIgaGVhZGVycyAoYW5k IHBvc3NpYmx5IGluIHRoZSBpbml0aWFsIHN0cmVhbXMpOiAodHJhaWxlcl9zdHJlYW1zKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaW9kaWNhbGx5LCBjbGVhciBiaXRz IG9mIGZyb20gdGhlIGJpdG1hcHMgYXMgc3RyZWFtcyBhcmUgY2xvc2VkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaGVuIGEgUVBBQ0sgZW5jb2RlciB3aXNoZXMgdG8gREVMRVRFIGEgc3RyZWFt LCBpdCBzZW5kcyBhIERlbGV0ZV9SZXF1ZXN0KGluZGV4LCBpbml0aWFsX3N0cmVhbXMsIHRyYWls ZXJfc3RyZWFtcykgb24gdGhlIENvbnRyb2wgQ2hhbm5lbCAoMykuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBRUEFDSyBkZWNvZGVyIChyZWNlaXZlciBvZiB0aGlzIERlbGV0ZV9SZXF1ZXN0 KSB3aWxsIGV4ZWN1dGUgdGhlIOKAnGRlbGV0ZeKAnSBhbmQgc2VuZCBEZWxldGVBY2soaW5kZXgp IHRvIHRoZSBDb250cm9sIENoYW5uZWwgKDMpLCB3aGVuOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5BbGwgaW5pdGlhbF9zdHJlYW1zIGhhdmUgcmVhZCB0aGVpciBpbml0aWFsIGhlYWRl cnMgKG9yIHJlc2V0IGJlZm9yZSB0aGF0KSwgYW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPkFsbCB0cmFpbGVyX3N0cmVhbXMgaGF2ZSBjbG9zZWQgKGkuZS4gcmVhZCB0aGVpciB0cmFp bGVyIGhlYWRlcnMgb3IgcmVzZXQgYmVmb3JlIHRoYXQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5VcG9uIHRoZSByZWNlaXB0IG9mIHRoZSBEZWxldGVBY2sgbWVzc2FnZSwgUVBBQ0sgZW5jb2Rl ciBpcyBmcmVlIHRvIHJldXNlIHRoZSBpbmRleC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+SWdvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtlIEJpc2hvcCBbbWFpbHRvOk1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5 IDI1LCAyMDE3IDY6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IFBhdHJpY2sgTWNNYW51cyAmbHQ7cG1j bWFudXNAbW96aWxsYS5jb20mZ3Q7OyBLYXp1IFlhbWFtb3RvICZsdDtrYXp1QGlpai5hZC5qcCZn dDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGFjayBmb3IgaW5zZXJ0aW9uIGluIFFQQUNLPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aGF04oCZcyBlc3NlbnRpYWxseSB3aGF0IEJ1Y2vigJlzIHByb3Bvc2FsIGJvaWxzIGRvd24gdG8s IEkgdGhpbmsg4oCTIHlvdSBjYW4gaW5zZXJ0LCBidXQgeW91IGNhbuKAmXQgcmVmZXJlbmNlIHVu dGlsIHlvdSBrbm93IGl04oCZcyBiZWVuIHNlZW4uJm5ic3A7IEEgcHJldmlvdXMgdmVyc2lvbiBv ZiBRUEFDSyBhbHNvIGhhZA0KIGFja3Mgb24gaW5zZXJ0cywgYnV0IHRoYXQgbWVhbnQgZG91Ymxl IHRoZSBhY2staGFuZGxpbmcgbG9naWMuJm5ic3A7IChBbmQgSSBkaWRu4oCZdCBibG9jayByZWZl cmVuY2VzIGJlZm9yZSB0aGUgYWNrLCBzaW5jZSB0aGF04oCZcyBzb21ldGhpbmcgYW4gZW5jb2Rl ciBjYW4gY2hvb3NlIHRvIGRvIG9yIG5vdCwgdHJhZGluZyBvZmYgbGFjay1vZi1IT0xCIHZlcnN1 cyBjb21wcmVzc2lvbiBlZmZpY2llbmN5Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5QYXRyaWNrIE1jTWFudXM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFy eSAyNCwgMjAxNyA5OjMzIFBNPGJyPg0KPGI+VG86PC9iPiBLYXp1IFlhbWFtb3RvICZsdDs8YSBo cmVmPSJtYWlsdG86a2F6dUBpaWouYWQuanAiPmthenVAaWlqLmFkLmpwPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmci PnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogYWNrIGZvciBp bnNlcnRpb24gaW4gUVBBQ0s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5j ZXJ0YWlubHkgYW4gaW1wbGVtZW50YXRpb24gY291bGQgY2hvb3NlIHlvdXIgYWxnb3JpdGhtLi4g YnV0IGEgcHJpbWFyeSB1c2UgY2FzZSAoYW5kIGJlbmVmaXQpIG9mIEhQQUNLIGlzIHNlbmRpbmcg TygxMDApIHJlcXVlc3RzIGluIHRoZSBmaXJzdCByb3VuZCB0cmlwIC0gYW5kIHRoYXQgc2NoZW1l IHdvdWxkIGRlZmVhdCB0aGF0ICh2aWEgY3duZCkuLiByZXF1ZXN0cyB0ZW5kIHRvIGNvbWUgaW4g YmF0Y2hlcw0KIGFuZCByZW1vdmluZyB0aGUgcmVkdW5kYW5jeSBpbiB0aGUgYmF0Y2ggd2l0aG91 dCBydHQgaXMgYSB1c2VmdWwgcHJvcGVydHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyNSwgMjAxNyBhdCAyOjIzIFBNLCBLYXp1IFlh bWFtb3RvICZsdDs8YSBocmVmPSJtYWlsdG86a2F6dUBpaWouYWQuanAiIHRhcmdldD0iX2JsYW5r Ij5rYXp1QGlpai5hZC5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpLDxicj4NCjxicj4NCldoYXQgd2ls bCBoYXBwZW4gaWYgd2UgY2hhbmdlIHRoZSBjdXJyZWN0IFFQQUNLIGFzIGZvbGxvd3M6PGJyPg0K PGJyPg0KLSBJbnNlcnRpb25zIGFsc28gcmVxdWlyZSBhY2tzLjxicj4NCi0gQW4gZW5jb2RlciBj YW4gdXNlIGFja2VkLWluZGNlcyBvbmx5Ljxicj4NCi0gSWYgYSBub24tYWNrZWQgZW50cnkgZXhp c3RzIGZvciBhIG5hbWUtdmFsdWUsIHRoZSBlbmNvZGVyPGJyPg0KJm5ic3A7IGVuY29kZXMgdGhl IGVudGlyZSBvZiBuYW1lLXZhbHVlIHdpdGhvdXQgdXNpbmcgaXRzIGluZGV4Ljxicj4NCjxicj4N CkRvZXMgdGhpcyBtYWtlIFFQQUNLIEhvTC1mcmVlPzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLUthenU8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_64484f337f934b4b879fc40e0143921fusma1exdag1mb5msgcorpak_-- From nobody Thu Jan 26 01:40:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F026129509 for ; Thu, 26 Jan 2017 01:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8VKV68Vg9pT for ; Thu, 26 Jan 2017 01:40:14 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6540129508 for ; Thu, 26 Jan 2017 01:40:12 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id r126so63662353wmr.0 for ; Thu, 26 Jan 2017 01:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=YpFkybfphSp31ZYUtLvgKpM/He9wwf5ntIHI4LOiCmc=; b=vGWCtdE8Nfi2vTjrpBNZQw4tEoAxr6dfplsSki2vEX1HVfezVpwf9cV6gO1bEKTg9I pKiwM661FyB0IZDV0wtuhrHDkWs8DOuGCrj27eN8NZ0oOG0x50j9RD8caeiE4fxUGRWW K03ilMKdPJqHcd+yKZHiCg01GTb0Jo8gwpXDbpaSUkC6LJcRYdP4cNmIo3HATzGQmApk +Zq7djDzjbYSKktiqgb2+OVm+hMXmhaYI58n7YH/ROlGHTFNOY4Q5F0dmTAo8IpzjuWc FC4DtMt8tfilT/xr1bm/eEF3HkDs13b1SmF1xMKeeCikOxNXo78pe+hIePEpUh6QuABT 4Wjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=YpFkybfphSp31ZYUtLvgKpM/He9wwf5ntIHI4LOiCmc=; b=kcJ7A+hBLIMlNhXai7Yk1fSHluWMqh0NRY5w3CGXg7LIdDwDZz67qEraTYaABd4Ew4 XOSit9zbwrZl1rXWQHJnSQPfT5i29GP5uaW9MiEZDD0C6IavNO729jvIpCDGSUIwMBEM /6oDI78+3hp75ixqBnkz5GaXoUJyJxVwhsnX091YKmnregt3hd8sjGmOSjWRHzaJbzLh NQ5Rs0RGbdRR3m5wqIUz23YlyWQcEWxROUO9nJFR9llFWyO5mtX4+BviI+9fHMUC3fTd QCIsoanBbyACFeCynE6P2W1eVap2OYl9r5oH1DE2+H8OjHTLeKcMlzsrnoPpcgJyufGx iwMw== X-Gm-Message-State: AIkVDXJfOgZvnKd5NbKXA+GMquVsoxXkYhThggOlhqNnEMDpn4BxnrJ0KJ3x6XFluOSPwrLx X-Received: by 10.28.61.136 with SMTP id k130mr1704634wma.128.1485423611031; Thu, 26 Jan 2017 01:40:11 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:48a9:7f7e:6d79:520f]) by smtp.gmail.com with ESMTPSA id o143sm2782988wmd.3.2017.01.26.01.40.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 01:40:10 -0800 (PST) To: quic@ietf.org, "ingemar.s.johansson@ericsson.com" From: marcelo bagnulo braun Subject: about draft-johansson-quic-ecn-00 Message-ID: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> Date: Thu, 26 Jan 2017 10:40:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 09:40:17 -0000 Hi, I have read the draft and i think it is a good starting point for this issue. thanks for writing it. My main comment is about the ECN negotiation. I am unconvinced that the quic version negotiation is the right approach for this. I mean, afaiu, quic version negotiation imposes an extra RTT when the new version is not supported. I think this is ok for major version changes, but I dont think this is appropriate for feature negotiation such as ECN. I mean, unless ECN is supported by default in the first quic version, I think using quic version negotiation for ECN support would be an obstacle in ECN adoption in quic. I mean, if we end up in the situation that the first (widely deployed) quic protocol specification does not support ECN by default, then having ECN negotiation using quic version will imply that if a client wants to tries to see if the server supports ECN, it risks to have a extra RTT penalty. (i understand the client can cache which servers support ECN, but we are back into working around these difficulties that make ecn adoption harder). The other problem is related to the blocking of ECN bits in the IP header. Ideally, I guess, the client should be able to learn if the ECN bits are blocked during the negotiation phase i.e. the negotiation can fail either because the server doesnt support it or because the network doesnt support it. Because of this, I would argue that the good approach is to have the ECN bits set in the IP header of the packet carrying the ECN negotiation. So, with all this, I think it may be a better approach to make ECN negotiation to be done using a new frame type that is sent in the stream 1. This would be a message that the sender issues, after the connection has been established, to request ECN support from the other endpoint. This message would be sent in an ECN marked packet, to verify that the network delivers the message. The other endpoint can reply with another message accepting of not the ECN support for the connection. I think this approach has the benefit of not imposing extra latency for those who want to check if ECN is supported and at the same time verifies that the network is able to deliver ECN marked packets. If any of these conditions fail, the negotiation fail. Moreover, i think these messages can be used to disable ECN in the middle of the connection. One case where this can be useful is in a mobility scenario, where one of the endpoints move and in order to check if the new path still supports ECN, they can resend the option and see if the packets still make it. I guess more complicated verification methods could be built into this. thoughts? regards, marcelo From nobody Sun Jan 29 18:46: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 1EF83129851 for ; Sun, 29 Jan 2017 18:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hks16TidBBcz for ; Sun, 29 Jan 2017 18:46:53 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0109.outbound.protection.outlook.com [104.47.40.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588A3127ABE for ; Sun, 29 Jan 2017 18:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W6MNsI/abMsaQmqqhfFcWUuL6sOy/+VoazSmuF+3Gdk=; b=BsBkQxXu5uyAHGOxtEL7oZSw6Qt3LqCh5rfv3wKGGCnW9la+YJUoa+WtsIttfXXlsOwYX/Oub1XwKX8lmyYrEsXa5rif155AlnIRSbfgyw4XRVXQ4UigCqU7+bl4vdSEzlUvL0APdWN3iUphy+h/fqsqiGobO2u1czWWeitXT58= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 30 Jan 2017 02:46:50 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.026; Mon, 30 Jan 2017 02:46:50 +0000 From: Mike Bishop To: IETF QUIC WG Subject: RE: Splitting QPACK Thread-Topic: Splitting QPACK Thread-Index: AdJ30+1U3c1mTWZdTYamExCwb70oCACzn2/w Date: Mon, 30 Jan 2017 02:46:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [72.21.225.66] x-ms-office365-filtering-correlation-id: 2d9ff739-da2d-4421-72b2-08d448ba3da6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401076); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:TS9BIa9MdBDctttdbK96R4IlNgfPcuuLJR2shta4PUr21zxvnJdkDKIFyduZ2rX3ZbkmZuv1tRMXuLMfxEjI74M7fuzEddG7qU90BgZ9anYay8vBXWqel5g/CKxtyHdXpi6mVLk+nm1xfhcexCnBQNFhuFSDuUnEmJfk1sfC2bzxCZ4HvymM13pLkUlPi+BDkqR50Z7AEstQcOmsEAzwG4krHaCUCk8vPXfHISKFb8bxHp0Z76JcwCPN+RzFauudFTiaCBNs0zgSQdlBDk7QqYC7KzJPtYLQIbk65pGOOvt8wxm/UV/77DBwxa4hDFePTt9ehqG9zkgAUtu6xvoTzeVGRWIm0a4cVFr1oe3PWbk4kUdUuqtKx6YOHH2yaf6UIvavblXLqUz6cizdrQcIDc9rc6ZzPx5xqEHuGGMr4EVdk/K4agT5+IEhpgA9SFghtFWIwMYnUrClxWZpmFWZHHeb1RzuXs3vEM7kuYOKK9k= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39860400002)(39850400002)(39450400003)(39840400002)(189002)(199003)(76104003)(377454003)(2900100001)(74316002)(10090500001)(7736002)(236005)(86612001)(189998001)(122556002)(76176999)(3660700001)(7906003)(54356999)(97736004)(107886002)(50986999)(2906002)(3900700001)(221733001)(6116002)(450100001)(790700001)(102836003)(3846002)(53936002)(6506006)(77096006)(229853002)(38730400001)(6436002)(606005)(561944003)(2950100002)(6916009)(8990500004)(105586002)(66066001)(54896002)(6306002)(99286003)(25786008)(101416001)(9686003)(55016002)(33656002)(8676002)(8936002)(86362001)(81156014)(81166006)(92566002)(3480700004)(3280700002)(110136003)(5660300001)(7116003)(68736007)(7696004)(5005710100001)(10290500002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708ED4505BECF3723943580874B0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 02:46:49.9626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 02:46:56 -0000 --_000_BN6PR03MB2708ED4505BECF3723943580874B0BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Expanding audience. I'm not entirely convinced the complexity is worthwhil= e, but this is where I would head if we're comfortable with it. However, t= he added complexity buys us something. This solves the RST problem without= the weird behavior of saying that RSTs on the data stream imply the real s= tate of the request, for example. It also mostly solves the deadlock issue= (so long as the dedicated stream has priority over everything else when yo= u're allowed to send, you can't cause a deadlock on the request streams. Also, if we go this way, the remaining reasons to separate headers and data= seem to have disappeared, and we might be able to get down to one stream p= er request. From: Mike Bishop Sent: Thursday, January 26, 2017 5:01 AM To: 'Martin Thomson' ; 'Jana Iyengar' ; Patrick McManus Subject: Splitting QPACK I took a shot on the plane at splitting QPACK up differently. I reserve on= e stream (TBD exactly which) to do all table manipulations, and everything = on the streams only references the table. That solves the RST vulnerabilit= y nicely... but diverges even further from HPACK and brings us back toward = HOLB potentially existing between all streams (assuming that most streams n= eed to add something to the table). Take a look at https://mikebishop.github.io/http-misc-extensions/split_qpac= k/draft-bishop-quic-http-and-qpack.html and see what you think, though. Ha= lfway between a thought experiment and a serious proposal. --_000_BN6PR03MB2708ED4505BECF3723943580874B0BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Expanding audience.  I’m not entirely con= vinced the complexity is worthwhile, but this is where I would head if we&#= 8217;re comfortable with it.  However, the added complexity buys us so= mething.  This solves the RST problem without the weird behavior of saying that RSTs on the data stream imply the real state of th= e request, for example.  It also mostly solves the deadlock issue (so = long as the dedicated stream has priority over everything else when youR= 17;re allowed to send, you can’t cause a deadlock on the request streams.

 

Also, if we go this way, the remaining reasons to se= parate headers and data seem to have disappeared, and we might be able to g= et down to one stream per request.

 

From: Mike Bishop
Sent: Thursday, January 26, 2017 5:01 AM
To: 'Martin Thomson' <martin.thomson@gmail.com>; 'Jana Iyengar= ' <jri@google.com>; Patrick McManus <mcmanus@ducksong.com>
Subject: Splitting QPACK

 

I took a shot on the plane at splitting QPACK up dif= ferently.  I reserve one stream (TBD exactly which) to do all table ma= nipulations, and everything on the streams only references the table. = That solves the RST vulnerability nicely... but diverges even further from HPACK and brings us back toward HOLB potent= ially existing between all streams (assuming that most streams need to add = something to the table).

 

Take a look at https://mikebishop.github.io/http-misc-extensions/split_qpack/draft-bishop-= quic-http-and-qpack.html and see what you think, though.  Halfway = between a thought experiment and a serious proposal.

--_000_BN6PR03MB2708ED4505BECF3723943580874B0BN6PR03MB2708namp_-- From nobody Sun Jan 29 19:11: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 0121A127ABE for ; Sun, 29 Jan 2017 19:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 wETJeqOVQiwS for ; Sun, 29 Jan 2017 19:11:51 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD31126CD8 for ; Sun, 29 Jan 2017 19:11:50 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id c85so195610779wmi.1 for ; Sun, 29 Jan 2017 19:11:50 -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=CWlBNHlLiTWhsKj1+jjTU21Zy/7TWZ8ClUupGaQYkKc=; b=G+JmCxjVhay0yrLZlu3wDnyTSYrAdlMM4oYYzqZ6n+exWKKQ7dUusC3tFfFFUmduwF ekTd34+kIiIwaPHCPmDvdueOfn18wmZrIrot3oxtK0APV7Vvojkmg3DuiIh8zY/ZJsHg ZOwPoIDCQ3wpgxeW6DqURWiZR+ebtOU+2z1PBG6vFvXfM3GC9wxxq9FI9E+9RFdOtH8n Cm5card0V2UvoGhM6qDdul0Vr8PMJQDYsxFJl/Mw6RkkcExPmKmd6o3g6Yv81mSMk7vD GSaNYOA+hHB2Xt6k9MfbKS1btFvnF3350DoeDq6MBbUGzBWT/VNz+uhiZ57H5xct8ddf Gxsw== 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=CWlBNHlLiTWhsKj1+jjTU21Zy/7TWZ8ClUupGaQYkKc=; b=MSNySXZcqbIlrCLUjuVhwmHWoI4P+MWaCPV7+x4MPtgeL6Deo0+JEGNKMLIpJxSZqI cPFErPyokIQ/FW34OBDV4moYngHdRDRhoyQDBKU99/CqdtUIDKUIYOqSatOWQfx8cjuH yQTvhLlhTFd37640c01myp6g4Kk2Y0jCFs/A1PjLU56QUY6NDyl5j8JzjIz2wtNQcYcn t+tVcwKXNwFV2UyjHbuNcQEYuLGaI06+2nDpZiIqQpqReMYY1DIT37PqHrFGiFoMwPvP FpAP/Q7ZJeNW5j8IsKXh7iYhptmobxHQPnoNSfIZUswMBtqhy5VXzUVF4cZkK0snPoX9 NOVg== X-Gm-Message-State: AIkVDXKalGUeeHEh8rZZlUdAiB8eDw0W85MDxe1YtD3xz8tXpa0w/eelE6Fn3l8KC+7z1x7wqrwY1AnI3Ry53ILX X-Received: by 10.223.172.17 with SMTP id v17mr16369361wrc.115.1485745909104; Sun, 29 Jan 2017 19:11:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Sun, 29 Jan 2017 19:11:48 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Sun, 29 Jan 2017 19:11:48 -0800 Message-ID: Subject: Re: Splitting QPACK To: Mike Bishop Content-Type: multipart/alternative; boundary=f403045cf0ae23beca0547472dcd Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 03:11:52 -0000 --f403045cf0ae23beca0547472dcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop wrote: > Also, if we go this way, the remaining reasons to separate headers and > data seem to have disappeared, and we might be able to get down to one > stream per request. > > We'd still need some mechanism, within a stream, to delimit headers data from body data, right? Using two QUIC streams solves this problem nicely.= =E2=80=8B I don't love adding more intra-stream framing, if we can avoid it. --f403045cf0ae23beca0547472dcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Also, if we go this way, the remaining re= asons to separate headers and data seem to have disappeared, and we might b= e able to get down to one stream per request.


We'd stil= l need some mechanism, within a stream, to delimit headers data from body d= ata, right? Using two QUIC streams solves this problem nicely.=E2=80=8B I d= on't love adding more intra-stream framing, if we can avoid it.
--f403045cf0ae23beca0547472dcd-- From nobody Sun Jan 29 19:45: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 52A2E1293D6 for ; Sun, 29 Jan 2017 19:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW29dBT7pe4w for ; Sun, 29 Jan 2017 19:45:10 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0136.outbound.protection.outlook.com [104.47.33.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D484A127735 for ; Sun, 29 Jan 2017 19:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q+DIoRiF2P/BPMs74SgUZ7lZClSDwn/Ghq3k15QPKwE=; b=h7LVn4nm5qVJc7a1d6oUYGgCmnwGNdS8mqye9r815rbk5gR3RBS5ZzJVR4L2AY8mTWHsvV4NrdnYnl+B9QNghT1YPqV18bNJ6/Ma3xmZ0NEhWOPM+IBHNQ7+Yf2KrKV7QwdmAjhxF11Rwqdsuk3eVzXw6CgUcyEghCi3vJzYf+s= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 30 Jan 2017 03:45:07 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.026; Mon, 30 Jan 2017 03:45:07 +0000 From: Mike Bishop To: Ryan Hamilton Subject: RE: Splitting QPACK Thread-Topic: Splitting QPACK Thread-Index: AdJ30+1U3c1mTWZdTYamExCwb70oCACzn2/wAAELOgAAARWsoA== Date: Mon, 30 Jan 2017 03:45:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [72.21.225.66] x-ms-office365-filtering-correlation-id: d4899791-ac0d-446c-a8ba-08d448c26279 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:fjcBjZcrpjm23Mm7tLHz2CIEJOR5n8QMAK89uIvFoaWFFGbBgOs1VYa2VFEtB2Tt2rVcpH8ztG/NDukTCMt+9d8q/UcI0068x+mYav/LHG/kOPrt7ZGn1h9fLh8G7UqavtFqZkq5uvMuQrRTqK66eHRgvu/Ct0eDh8iBZS8fLJKKKk663f0Vh8fOk+Ww513YALKwukoGWOh+kOBC6H1TGE144V8NQwBdoaLrjTlvnnVGRLsay8+sejgQ1anUPfu0z4Lx53qKTwR28uANH9Dw0PxhW+b+GVNqnW0x0irwR7wplipWmzMNyos1rATNMfbQOgotHs8MNQynKlTH8Tgg+pjbD68X4+o83nFODWj5tUXo2GFTYNzRsszoTOxtdMH/bRbRBJu3pKhs6rATPZTFFpy51QDX+dlthZnlJgyXEr0LfCnKvkvffNWNuV+gZjHzaLK4SceN8VSMW2lnKNG962Wfg+filz+SoaOOAPAswxA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6042181)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(199003)(377454003)(3660700001)(7116003)(54356999)(76176999)(106356001)(74316002)(4326007)(5660300001)(50986999)(53936002)(105586002)(236005)(7736002)(6116002)(3480700004)(8990500004)(68736007)(19609705001)(3846002)(102836003)(790700001)(2906002)(101416001)(33656002)(3280700002)(77096006)(10090500001)(92566002)(6306002)(7696004)(54896002)(25786008)(9686003)(221733001)(38730400001)(122556002)(86362001)(8936002)(10290500002)(110136003)(81156014)(86612001)(81166006)(2950100002)(8676002)(5005710100001)(99286003)(6506006)(55016002)(66066001)(6916009)(2900100001)(189998001)(6436002)(97736004)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27083865BEBA1EFADE16160F874B0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 03:45:07.7306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 03:45:12 -0000 --_000_BN6PR03MB27083865BEBA1EFADE16160F874B0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBpdCB3b3VsZCBtZWFuIGJyaW5naW5nIGJhY2sgdGhlIERBVEEgZnJhbWUgZnJvbSBIVFRQ LzIuICBHaXZlbiB0aGF0IHdlIGFscmVhZHkgaGF2ZSBpbnRyYS1zdHJlYW0gZnJhbWluZyAob24g b25lIHN0cmVhbSBvZiB0d28pLCB0aGF0IGRpZG7igJl0IHNlZW0gbGlrZSBhIGJpZyBsb3NzIHRv IG1lLiAgSG93ZXZlciwgSSBjYW4gYmVsaWV2ZSB0aGF0IHRoZXJlIGFyZSBwZXJmb3JtYW5jZSBl ZmZpY2llbmNpZXMgdG8gYmUgZ2FpbmVkIGZyb20gYmVpbmcgYWJsZSB0byBkaXNwZW5zZSB3aXRo IGZyYW1pbmcgb25jZSB5b3UgZ2V0IHRvIHRoZSBib2R5Lg0KDQpGcm9tOiBSeWFuIEhhbWlsdG9u IFttYWlsdG86cmNoQGdvb2dsZS5jb21dDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMjksIDIwMTcg NzoxMiBQTQ0KVG86IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPg0K Q2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTcGxpdHRpbmcg UVBBQ0sNCg0KDQpPbiBTdW4sIEphbiAyOSwgMjAxNyBhdCA2OjQ2IFBNLCBNaWtlIEJpc2hvcCA8 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9z b2Z0LmNvbT4+IHdyb3RlOg0KQWxzbywgaWYgd2UgZ28gdGhpcyB3YXksIHRoZSByZW1haW5pbmcg cmVhc29ucyB0byBzZXBhcmF0ZSBoZWFkZXJzIGFuZCBkYXRhIHNlZW0gdG8gaGF2ZSBkaXNhcHBl YXJlZCwgYW5kIHdlIG1pZ2h0IGJlIGFibGUgdG8gZ2V0IGRvd24gdG8gb25lIHN0cmVhbSBwZXIg cmVxdWVzdC4NCg0KV2UnZCBzdGlsbCBuZWVkIHNvbWUgbWVjaGFuaXNtLCB3aXRoaW4gYSBzdHJl YW0sIHRvIGRlbGltaXQgaGVhZGVycyBkYXRhIGZyb20gYm9keSBkYXRhLCByaWdodD8gVXNpbmcg dHdvIFFVSUMgc3RyZWFtcyBzb2x2ZXMgdGhpcyBwcm9ibGVtIG5pY2VseS7igIsgSSBkb24ndCBs b3ZlIGFkZGluZyBtb3JlIGludHJhLXN0cmVhbSBmcmFtaW5nLCBpZiB3ZSBjYW4gYXZvaWQgaXQu DQoNCg== --_000_BN6PR03MB27083865BEBA1EFADE16160F874B0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlllcywgaXQgd291bGQgbWVhbiBicmluZ2luZyBiYWNrIHRoZSBE QVRBIGZyYW1lIGZyb20gSFRUUC8yLiZuYnNwOyBHaXZlbiB0aGF0IHdlIGFscmVhZHkgaGF2ZSBp bnRyYS1zdHJlYW0gZnJhbWluZyAob24gb25lIHN0cmVhbSBvZiB0d28pLCB0aGF0IGRpZG7igJl0 IHNlZW0gbGlrZSBhIGJpZyBsb3NzIHRvIG1lLiZuYnNwOyBIb3dldmVyLCBJIGNhbiBiZWxpZXZl IHRoYXQgdGhlcmUgYXJlIHBlcmZvcm1hbmNlIGVmZmljaWVuY2llcw0KIHRvIGJlIGdhaW5lZCBm cm9tIGJlaW5nIGFibGUgdG8gZGlzcGVuc2Ugd2l0aCBmcmFtaW5nIG9uY2UgeW91IGdldCB0byB0 aGUgYm9keS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBSeWFuIEhhbWlsdG9uIFttYWlsdG86cmNoQGdvb2dsZS5jb21dIDxicj4N CjxiPlNlbnQ6PC9iPiBTdW5kYXksIEphbnVhcnkgMjksIDIwMTcgNzoxMiBQTTxicj4NCjxiPlRv OjwvYj4gTWlrZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBTcGxpdHRpbmcgUVBBQ0s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBTdW4sIEphbiAyOSwgMjAxNyBhdCA2OjQ2IFBNLCBNaWtlIEJpc2hvcCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2Js YW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNvLCBpZiB3ZSBn byB0aGlzIHdheSwgdGhlIHJlbWFpbmluZyByZWFzb25zIHRvIHNlcGFyYXRlIGhlYWRlcnMgYW5k IGRhdGEgc2VlbSB0byBoYXZlIGRpc2FwcGVhcmVkLCBhbmQgd2UgbWlnaHQgYmUgYWJsZSB0byBn ZXQgZG93biB0byBvbmUgc3RyZWFtIHBlciByZXF1ZXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPldlJ2Qgc3RpbGwgbmVlZCBzb21l IG1lY2hhbmlzbSwgd2l0aGluIGEgc3RyZWFtLCB0byBkZWxpbWl0IGhlYWRlcnMgZGF0YSBmcm9t IGJvZHkgZGF0YSwgcmlnaHQ/IFVzaW5nIHR3byBRVUlDIHN0cmVhbXMgc29sdmVzIHRoaXMgcHJv YmxlbSBuaWNlbHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj7igIs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj4NCiBJIGRvbid0IGxvdmUgYWRkaW5nIG1v cmUgaW50cmEtc3RyZWFtIGZyYW1pbmcsIGlmIHdlIGNhbiBhdm9pZCBpdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB27083865BEBA1EFADE16160F874B0BN6PR03MB2708namp_-- From nobody Sun Jan 29 20:29: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 EA46A1293F8 for ; Sun, 29 Jan 2017 20:29:13 -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 nde1vB0dpSkw for ; Sun, 29 Jan 2017 20:29:13 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56BF127ABE for ; Sun, 29 Jan 2017 20:29:12 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id c85so197051961wmi.1 for ; Sun, 29 Jan 2017 20:29:12 -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=yZbaEyi0MuB2keJKIKtYKa66GKpWTrsLarBagMEkwM0=; b=fCEwHyIFDzio8eHS94t+4Qke1zZ8j9KVlj6HOlfyx0MNsNtNH9YtJ3Uh6RM3DgHC64 yKHFLmaQ2iT/wumLVGHWogXHJ6ThprJGZi3srC6eAoR1BHlf+dP9f3oCrFehoeL5eZbm 0MqC9b4zqiI1PrB5PnX/641XgQ1uGmjrtI4g7XZZ1Z3gdv1pEdfqDWGE/Uj35uLPHtyO DlALer32oksu+jSytx5rfMcOzoLgwZ5tAXQ+0BclewXQbK6Isfhxn19F7b8HsuCQZgPN i6RN1za2V8huCrpZnSk5mfa0lU/SyDdqYm6YdyvWLJN26A4Zm532SIP/yd3ObffTwzsh 0fLQ== 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=yZbaEyi0MuB2keJKIKtYKa66GKpWTrsLarBagMEkwM0=; b=m4IwOsOcVgISH2r/VoRpfKP2sjCEb0tdGg0PObvqIAvd6dV+xAvAJju21RwbXXGTn9 1abGWaarsgthy8g/U0d/qbaVWUiM28FZNHJhFg35/6P1CqlFIMiUYgSJnatB7bYAZFuP 6p3pOM7d7NL+i7uRla4uVgb2cx+i2njmQ2B58Ar9XQdmU4G5aN1G9lf5UuQHUe5dRWm3 doZI+7HabgAP05uuMinZ06DZ2pqQHCbCLf+AeGa4g3Js6F+Qy2Z5ukqAHtSkCMgUThNQ u/LcP1FNjIww2UQkROi7kLebaMiiizak3DBmbfWKze3GIUnlR+D1V9LC/AvEOkGub9JU jiLg== X-Gm-Message-State: AIkVDXLLF4XyvdsayQ6mMsFXzoUfnp4MPnNeiBEnwIZQAne9VR2M5AAhsHyDojJSSUyqty4lBBllIPo/Arrn6Q== X-Received: by 10.28.210.139 with SMTP id j133mr11683692wmg.67.1485750551258; Sun, 29 Jan 2017 20:29:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.130 with HTTP; Sun, 29 Jan 2017 20:29:10 -0800 (PST) In-Reply-To: References: From: Watson Ladd Date: Sun, 29 Jan 2017 20:29:10 -0800 Message-ID: Subject: Re: Splitting QPACK To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 04:29:14 -0000 On Sun, Jan 29, 2017 at 7:11 PM, Ryan Hamilton wrote: > > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop > wrote: >> >> Also, if we go this way, the remaining reasons to separate headers and >> data seem to have disappeared, and we might be able to get down to one >> stream per request. > > > We'd still need some mechanism, within a stream, to delimit headers data > from body data, right? Using two QUIC streams solves this problem nicely. I > don't love adding more intra-stream framing, if we can avoid it. Correct me if I'm wrong, but the additional stream shouldn't add any more latency as it will be opened together with the first one. Why do we need to get down to one stream per request? > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Jan 29 20:32: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 3E100120727 for ; Sun, 29 Jan 2017 20:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 q4mUpLnCABTB for ; Sun, 29 Jan 2017 20:32:50 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1054127ABE for ; Sun, 29 Jan 2017 20:32:49 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id r141so15582908wmg.1 for ; Sun, 29 Jan 2017 20:32:49 -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=2OW5nTWrXJitP2qx76aOm4G+4Xgf5pIPlghCp7/7i4o=; b=ECQa2coh0MxQkHgJ94FKswVwaGY3m6G8mVPBvQ1Co5iCDYnIo1bBX6I/xfNMoZT7Z2 dyep1adOg6AbhZnB+Jwh0BrTlOos7qoMSNzOOZvBzNvWcJWsGg6fV2KAOsptnW6uN4BG Regti8+FkRhz/omScTp2M6JIQVAuTjJcSn3tf4vEtMKEgkkIv8fYG0KdkSJW6wXU/gw6 POItGapyd7lQ08LqPk6EMC+ZWSNZyxELkEgv+l6AzE8on385yMMX+KQaoi41eTfa3hEy JMFFmSsnoEzbFWxCbrzYKVobDC4vJeyT3QX2k0wHAZdmbXt9NC7J+S68i6ZNs1D+Bwq6 clhw== 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=2OW5nTWrXJitP2qx76aOm4G+4Xgf5pIPlghCp7/7i4o=; b=pB5jOLhftjCfl4NsCEEsk82rAiVn3oQFRJ+FVagPQvZe7hWY9yACqTs3lUudWOajTO 8U4eW29KHXpKiCfp++COaIpQJBr1AYZd1BjyTfETMgHh18q4dxerMGYZTY/5p2hH8yDj Zo3ItHm5zf/J++Ku/aYiQxD06RnO+9+zCi1fsFbECduhHBp+LGMjZV8gfNdmcq0OyoT1 qMzGELom+oPKbvlnhzyi5XQoP70Tu/0qW0Syte+LSx9jELvJ+SckcoZPkjEeUJx7ai7q 7EhiKaI+kMN2Dbej94G6V+AC7bsuDzlW76fshVTBFyQqNdAwffrdgkLq9pogGX+xMbho 4TYQ== X-Gm-Message-State: AIkVDXJsiz05zdO5UNWnGopD4OxLJRSBYnef0rhKbynpFai4HYk83kUzN0NuuGr4aAurwcsacmP7VCqffOSiIkWC X-Received: by 10.223.145.163 with SMTP id 32mr19606100wri.198.1485750768080; Sun, 29 Jan 2017 20:32:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Sun, 29 Jan 2017 20:32:47 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Sun, 29 Jan 2017 20:32:47 -0800 Message-ID: Subject: Re: Splitting QPACK To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c0df084c1e5340547484eb0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 04:32:52 -0000 --94eb2c0df084c1e5340547484eb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Exactly. Adding HTTP/2 DATA frame overhead (or perhaps something similar) is not the end of the world by any means and if we end up going that route, so be it. On the other hand, by using the existing stream_id field of the QUIC STREAM frame, we'll be able to differentiate headers from body without burning any extra bytes on the wire, so that appeals to me. On Sun, Jan 29, 2017 at 7:45 PM, Mike Bishop wrote: > Yes, it would mean bringing back the DATA frame from HTTP/2. Given that > we already have intra-stream framing (on one stream of two), that didn=E2= =80=99t > seem like a big loss to me. However, I can believe that there are > performance efficiencies to be gained from being able to dispense with > framing once you get to the body. > > > > *From:* Ryan Hamilton [mailto:rch@google.com] > *Sent:* Sunday, January 29, 2017 7:12 PM > *To:* Mike Bishop > *Cc:* IETF QUIC WG > *Subject:* Re: Splitting QPACK > > > > > > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop > wrote: > > Also, if we go this way, the remaining reasons to separate headers and > data seem to have disappeared, and we might be able to get down to one > stream per request. > > > > We'd still need some mechanism, within a stream, to delimit headers data > from body data, right? Using two QUIC streams solves this problem nicely.= =E2=80=8B > I don't love adding more intra-stream framing, if we can avoid it. > > > --94eb2c0df084c1e5340547484eb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exactly. Adding HTTP/2 DATA frame overhead (or perhaps som= ething similar) is not the end of the world by any means and if we end up g= oing that route, so be it. On the other hand, by using the existing stream_= id field of the QUIC STREAM frame, we'll be able to differentiate heade= rs from body without burning any extra bytes on the wire, so that appeals t= o me.

On Sun= , Jan 29, 2017 at 7:45 PM, Mike Bishop <Michae= l.Bishop@microsoft.com> wrote:

Yes, it would mean bringing back the DATA frame from= HTTP/2.=C2=A0 Given that we already have intra-stream framing (on one stre= am of two), that didn=E2=80=99t seem like a big loss to me.=C2=A0 However, = I can believe that there are performance efficiencies to be gained from being able to dispense with framing once you get to the = body.

=C2=A0

From: Ryan Hamilton [mailto:rch@google.com] Sent: Sunday, January 29, 2017 7:12 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Splitting QPACK

=C2=A0

=C2=A0

On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Also, if we go this way, the remaining reasons to se= parate headers and data seem to have disappeared, and we might be able to g= et down to one stream per request.

=C2=A0

We'd still need some mechanism, within a stream, to delimit= headers data from body data, right? Using two QUIC streams solves this pro= blem nicely.=E2=80=8B I don't love adding more intra-stream framing, if we can avoid it.<= /u>

=C2=A0


--94eb2c0df084c1e5340547484eb0-- From nobody Mon Jan 30 06:32: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 9259A12999A for ; Mon, 30 Jan 2017 06:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPmgPaW0eSIW for ; Mon, 30 Jan 2017 06:32:29 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 08E9B1299A4 for ; Mon, 30 Jan 2017 06:32:21 -0800 (PST) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6E0783A0A3 for ; Mon, 30 Jan 2017 09:32:20 -0500 (EST) Received: by mail-qk0-f175.google.com with SMTP id u25so130146975qki.2 for ; Mon, 30 Jan 2017 06:32:20 -0800 (PST) X-Gm-Message-State: AIkVDXK7zIfGUMUg7Q18qdxWAfK0Gy8TwSpQuKybTFWTMsN3px8Sec6nWQd9SdoSLyTOILGXaf97ntZzpxaIPQ== X-Received: by 10.55.43.158 with SMTP id r30mr24671022qkr.28.1485786740179; Mon, 30 Jan 2017 06:32:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Mon, 30 Jan 2017 06:32:19 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Mon, 30 Jan 2017 15:32:19 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Splitting QPACK To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a1149430edc58b1054750aefd Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 14:32:32 -0000 --001a1149430edc58b1054750aefd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike - I like the new text quite a lot. It gives encoders a clear chance to decide when to risk holb and when to just inline things in literals; I think that flexibility is going to be key in working out the most effective approach. The horizon bits also read simpler than the unbounded reference counted model discussed in Tokyo even if it is more complex than the existing stream 3 approach. This is where I had been hoping we would end up= . In the grand scheme of things losses would likely be a very low percentage of the overall bytes where a loss could create a holb event - and even then it needn't be global. Good show. As for the 2 vs 1 stream discussion, I still prefer the 2 stream approach but its not a huge deal to me. hope your traveling is safe and swift. On Mon, Jan 30, 2017 at 5:32 AM, Ryan Hamilton wrote: > Exactly. Adding HTTP/2 DATA frame overhead (or perhaps something similar) > is not the end of the world by any means and if we end up going that rout= e, > so be it. On the other hand, by using the existing stream_id field of the > QUIC STREAM frame, we'll be able to differentiate headers from body witho= ut > burning any extra bytes on the wire, so that appeals to me. > > On Sun, Jan 29, 2017 at 7:45 PM, Mike Bishop > wrote: > >> Yes, it would mean bringing back the DATA frame from HTTP/2. Given that >> we already have intra-stream framing (on one stream of two), that didn= =E2=80=99t >> seem like a big loss to me. However, I can believe that there are >> performance efficiencies to be gained from being able to dispense with >> framing once you get to the body. >> >> >> >> *From:* Ryan Hamilton [mailto:rch@google.com] >> *Sent:* Sunday, January 29, 2017 7:12 PM >> *To:* Mike Bishop >> *Cc:* IETF QUIC WG >> *Subject:* Re: Splitting QPACK >> >> >> >> >> >> On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop < >> Michael.Bishop@microsoft.com> wrote: >> >> Also, if we go this way, the remaining reasons to separate headers and >> data seem to have disappeared, and we might be able to get down to one >> stream per request. >> >> >> >> We'd still need some mechanism, within a stream, to delimit headers data >> from body data, right? Using two QUIC streams solves this problem nicely= . >> =E2=80=8B I don't love adding more intra-stream framing, if we can avoid= it. >> >> >> > > --001a1149430edc58b1054750aefd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike - I like the new text quite a lot. It gives= encoders a clear chance to decide when to risk holb and when to just inlin= e things in literals; I think that flexibility is going to be key in workin= g out the most effective approach. The horizon bits also read simpler than = the unbounded reference counted model discussed in Tokyo even if it is more= complex than the existing stream 3 approach. This is where I had been hopi= ng we would end up.

In the grand scheme of things losses would likel= y be a very low percentage of the overall bytes where a loss could create a= holb event - and even then it needn't be global. Good show.

As for the 2 vs 1 stream discussion, I still prefer the 2 stream approac= h but its not a huge deal to me.

hope your traveling is safe a= nd swift.


On Mon, Jan 30, 2017 at 5:32 AM, Ryan Hamilton <= rch@google.com><= /span> wrote:
Exactly. A= dding HTTP/2 DATA frame overhead (or perhaps something similar) is not the = end of the world by any means and if we end up going that route, so be it. = On the other hand, by using the existing stream_id field of the QUIC STREAM= frame, we'll be able to differentiate headers from body without burnin= g any extra bytes on the wire, so that appeals to me.

On Sun, J= an 29, 2017 at 7:45 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Yes, it would mean bringing back the DATA frame from= HTTP/2.=C2=A0 Given that we already have intra-stream framing (on one stre= am of two), that didn=E2=80=99t seem like a big loss to me.=C2=A0 However, = I can believe that there are performance efficiencies to be gained from being able to dispense with framing once you get to the = body.

=C2=A0

From: Ryan Hamilton [mailto:r= ch@google.com]
Sent: Sunday, January 29, 2017 7:12 PM
To: Mike Bishop <Michael.Bishop@mic= rosoft.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Splitting QPACK

=C2=A0

=C2=A0

On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Also, if we go this way, the remaining reasons to se= parate headers and data seem to have disappeared, and we might be able to g= et down to one stream per request.

=C2=A0

We'd still need some mechanism, within a stream, to delimit= headers data from body data, right? Using two QUIC streams solves this pro= blem nicely.=E2=80=8B I don't love adding more intra-stream framing, if we can avoid it.<= /u>

=C2=A0



--001a1149430edc58b1054750aefd-- From nobody Mon Jan 30 09:08: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 317E1129563 for ; Mon, 30 Jan 2017 09:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 ct8XOps8WLSU for ; Mon, 30 Jan 2017 09:08:29 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E76B129559 for ; Mon, 30 Jan 2017 09:08:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vBwp34drqzMpRq for ; Mon, 30 Jan 2017 18:08:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OclqGnvISK9a for ; Mon, 30 Jan 2017 18:08:26 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC20FD.dip0.t-ipconnect.de [93.236.32.253]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA for ; Mon, 30 Jan 2017 18:08:26 +0100 (CET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Ossification Message-Id: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> Date: Mon, 30 Jan 2017 18:08:25 +0100 To: quic@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 17:08:31 -0000 Hi all, I kept thinking about the problem of ossification based on some = discussion we had last Thursday. Even if we try our best to make quic = headers as flexible as possible and try to maintain this by greasing, we = will still see ossification that we don=E2=80=99t want. I=E2=80=99m = mostly thinking about the connection ID in data packets here. I pretty = sure that we will see middblebox that will only check for the =E2=80=9Aspe= cial packet=E2=80=98 bit and assume to find the connection ID at a = certain position in the header if that bit is not set.=20 In general I see three approaches to face this problem: 1) Try to not expose any data at all (as soon as crypto context is = established). This would mean that we should not provide a connection ID = (meaning we will not support use cases where in network devices could = can make use of it) and we should encrypt the packet number. 2) Provide the version number in every packet. This would at least = increase the change that a middlebox would check the version number = before making further implicit assumptions. However, this would probably = ossify the version number we choose for the initial version as = middleboxes would probably just treat this as a magic number to detect = quic and are slow in updating. If we want to prevent that we would = probably also need something like an online registry, where a certain = number is mapped to a certain version and maybe even periodically change = that mapping=E2=80=A6? Not sure how brilliant that idea is=E2=80=A6 3) Decide for a common wire image for all quic packets now and fix that = for all version of quic. I know the intention of quic versioning would = be to be as flexible as possible but I don=E2=80=99t think this option = is as bad as it sounds. First of all, I believe we already have a good = idea of the limited set of information we want to provide to = middbleboxes (see below). And second, I'm also rather positive that if = we agree on this now, we anyway want to maintain this information for = all future versions of quic, given this should make deployment of future = versions in a middleboxed network easier/possible.=20 What I think we need is the following: - a magic number: similar as already discussed for the version = negotiation packet, this makes it super easy to recognize quic and = therefore takes away any incentives to misuse anything else for this = purpose. Note that one could still standardize another UDP-based = protocol (which we might then not be called quic anymore) with a = different magic number but deployment might be harder as soon as the = quic magic number is widely deployed. So this basically introduces = another kind of versioning with higher costs, while hopefully the actual = quic versioning will not be misused and can therefore be used to change = quic at low cost. - connection ID (as routing information; might be zero in the first = packet=E2=80=A6) - packet number (can be used for loss detection of losses that occurred = before the observation point if increased linearly without gaps), and - packet number echo (can be used for RTT measurements and proof of = return routability) And that=E2=80=99s it.=20 My 2c=E2=80=A6 Mirja From nobody Mon Jan 30 16:35: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 86781129721 for ; Mon, 30 Jan 2017 16:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4rx4ibyrbMd for ; Mon, 30 Jan 2017 16:35:39 -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 28CE71296F6 for ; Mon, 30 Jan 2017 16:35:39 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id k15so221044218qtg.3 for ; Mon, 30 Jan 2017 16:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=42lbG3k0EUON6UIqTiFc2oA+aUV5gaZ2R6wPDlXUQyw=; b=Xw5rJ17NvtGkOjtvlTwI/7565DrpkPsh3NUdKtzQ6PMQj1k9jHKgRY2qwAeI8M1Ec/ rkHyv1Cg5cg0BRve0fdtXHlDXZFHlN9OjhVFlWzpxjB0KxUQsMFjqroKGWu40+Q5DgjP kg6Ie60wqWnwnfANNDdXSK/OyVCcHW8kZSaf4iZWgNBrp9Lt1vhW8c2f9ixFNunWLcVV L/G3Dm+Q+GWsHBrBqCJ+1apFRT0R8EEkgnSsXHwqQsZkKI1ipseNbKO1UNcqRzet2F9y H8X1GexzZ9pRGv5K0pcWOJW8npyZ1BuSmau/2lRNAGivVD1GAsYkpf+liP2k5aNtLgte OcaQ== 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=42lbG3k0EUON6UIqTiFc2oA+aUV5gaZ2R6wPDlXUQyw=; b=sKq/Bc54I+0syOxL3+OR7w2STQG1Uk7i1iJa2J6mui30XvhTH2dS6xnhWb2AE+0LNu ispRZ+rvx79445Mbq6v2/LvPjVVC0VuQnLDJnS8VrKV8XjB6RmVGxR8J6b8up3uk0Qhc Rhgg58ByLzzHrmmmKXAYi7SP2wqXFBWy3FD+aps27Xfjojm6wcPqjcFCXXVeuVYTNtje zZKA8cgvogknrz+AkcvcQ/r29O7z+RGDzG0g2GIpiBrrihlzYMDpv4NKNZaGK20aS/lz xH/jZrfB3qVNV7s+Uixxs+rnq7fOx1RxTj8rnskv6RW/ScHd+1YGtY7bdw4U8SAMQIn7 s0/w== X-Gm-Message-State: AIkVDXKLqmG7Xw8ZieeTYGIheigsoadrQbRPo9Rwy5NyGbUxjKKt4htYZVnHx4txYs1j/aLkfB9K/w/E3Md4qg== X-Received: by 10.200.39.200 with SMTP id x8mr22720449qtx.159.1485822938278; Mon, 30 Jan 2017 16:35:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 30 Jan 2017 16:35:37 -0800 (PST) In-Reply-To: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> From: Martin Thomson Date: Tue, 31 Jan 2017 11:35:37 +1100 Message-ID: Subject: Re: Ossification To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 00:35:40 -0000 On 31 January 2017 at 04:08, Mirja K=C3=BChlewind wrote: > - packet number (can be used for loss detection of losses that occurred b= efore the observation point if increased linearly without gaps), and On this point, existing implementations skip packet numbers periodically. That looks like loss to the other side (or the path), but even spurious losses don't have a bit impact on things like congestion control if they are rare enough. One thing that we've discussed is the use of gaps to verify packet receipt after a connection migration. An endpoint that detects a move can start skipping more aggressively to protect against optimistic ack attacks on that new path. I guess that you could argue that echoing a packet number achieves the same effect more efficiently, but we would need to assess that in the context of the bytes it would expend overall. From nobody Mon Jan 30 17:52:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C604A129871 for ; Mon, 30 Jan 2017 17:52:04 -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 ghiPcM5T2cA2 for ; Mon, 30 Jan 2017 17:52:03 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615F81270B4 for ; Mon, 30 Jan 2017 17:52:03 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id j15so206383495oih.2 for ; Mon, 30 Jan 2017 17:52:03 -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=SRU4EOTZepYjv/uuhfUgnq/THQmYrp8QmXwXk5/IKO0=; b=bPZ62Ew3L57tzg3Lbt1S4Z6wL6ucUriLGzSQX4PE5u5GkJ2p248lOskNF9myy10EH8 YpBd5D1mLgAkwwPEglnoLtoQ4P8qsGbC2yrLYANL2jqPmPbWsRaYTcrguvVtPPVp1H/F /4JuqNTH3e/r1YOYySFhDba+gOgOpug4KV8SqapqtsCkqQPBkEk8uEjq1UwewnYsYYyo xWBLSs99P32rnGN7O1cbY061CNScSpy2aHZLtm9TDX/cuSv1b0Q/Ql4w7XYkYvpIp6Zx 5JwCLRq8xVAb/XPTQk9Cy3bvj2V0BLOLNxZF7lqGGcm8tUwHsLflRJ598A/2WbAKb6Ek lviw== 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=SRU4EOTZepYjv/uuhfUgnq/THQmYrp8QmXwXk5/IKO0=; b=DI77HUKb5vNtWUyu1D+yakFV7jCrHfekpgyo35Ln5RoIjyT8dwKt0xspYSbw9TbmWQ sYILh8r711KaVT45z7CN3SNOD14lCm43Cv2kjiaS5VopQj8Tpi/TVqf3TK2bPTpI8Qlx qEDLrUd8LyBu3xmNkWABwpRykC+BOWbGaGBkRXr6xyLhPIeiRCHZWBdYqpjVx/tLb5rf EEOHBChGz1EleRopvuGlrLojAObI/JKFDdEuWQZCyuNuz6zytKhUrzQ0f6lqHfnd0ZTJ k1L69BKMUY0n1lFs+6B90v0cvEzewHFdEuQsbVDxSYwzVXScyjyL3XCwAVJp4XJ7rAoA Zs5g== X-Gm-Message-State: AIkVDXKkcKaYfd++3O3/Hz1tv20eyBRgACcG3bc8XPqWlc6yDdzHDJdsUOhUya7vRXxcDNhIvB4gp/WmeCQ3Xg== X-Received: by 10.202.114.6 with SMTP id p6mr14414664oic.216.1485827522649; Mon, 30 Jan 2017 17:52:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.113 with HTTP; Mon, 30 Jan 2017 17:52:02 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Tue, 31 Jan 2017 10:52:02 +0900 Message-ID: Subject: Re: Splitting QPACK To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:52:05 -0000 2017-01-30 12:45 GMT+09:00 Mike Bishop : > Yes, it would mean bringing back the DATA frame from HTTP/2. Given that = we > already have intra-stream framing (on one stream of two), that didn=E2=80= =99t seem > like a big loss to me. However, I can believe that there are performance > efficiencies to be gained from being able to dispense with framing once y= ou > get to the body. My two cents go to using single stream for both headers and body, since I'd be worried of the maximum amount of memory that would be consumed by the per-stream receive windows. If we could send headers and body on a single stream then it would mean that the maximum number of streams that an endpoint becomes half when compared to current approach. That would in turn mean that the maximum amount of memory that needs to be allocated for the receive windows becomes half, or that the size of per-stream receive windows can be doubled while keeping the maximum same to the current draft. > > > From: Ryan Hamilton [mailto:rch@google.com] > Sent: Sunday, January 29, 2017 7:12 PM > To: Mike Bishop > Cc: IETF QUIC WG > Subject: Re: Splitting QPACK > > > > > > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop > wrote: > > Also, if we go this way, the remaining reasons to separate headers and da= ta > seem to have disappeared, and we might be able to get down to one stream = per > request. > > > > We'd still need some mechanism, within a stream, to delimit headers data > from body data, right? Using two QUIC streams solves this problem nicely.= I > don't love adding more intra-stream framing, if we can avoid it. > > --=20 Kazuho Oku From nobody Mon Jan 30 22:29:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E089129413 for ; Mon, 30 Jan 2017 22:29:05 -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 X83xOH0QKlYr for ; Mon, 30 Jan 2017 22:29:03 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 534EE1293FC for ; Mon, 30 Jan 2017 22:29:03 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id x49so224165547qtc.2 for ; Mon, 30 Jan 2017 22:29:03 -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=AhMtNGEelqABaU01qhKVfMACoEHshvQb9UEMo654ZsA=; b=RpSeWsXzq7yEr97xct+MalHlv24vzlQW6AZrVO6YDlQWD2vAMY6UUOAZ3DaafZZQnS aCKaRlQtqn7P5flD4xDdHbm56Nc6AJb/yTkLBq1MUBwgZV4B6LN+gL48gmrzkbhMgPXu Hwnl47ZU1quEeJgVDvd1ghPwD11BW3/W5nidhHrfua2Qnt2TpFQTNHEv8CpN94Ru/G3A cO50b7Kgqo8vROQ26l/rZN9Bjw9ZfbELI98arNrLwsyASbUrlFUHZCEweau5sMHZyYHA b2skEZz1NM1oEPqLNWC4f8PUDxDzYAeyVrkKaUk9dW3+fcWLItyIVsT5j0XQ7IOw4rSB KXQg== 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=AhMtNGEelqABaU01qhKVfMACoEHshvQb9UEMo654ZsA=; b=O5/mgaGr+ChLGaxOMtsIKNAylXa3KuhD04R4QVN9CST4CXN5ysZB8SM3hEMNfKbLvD YspWGax1ihIXl7R1DNlmjWjrWvuSq8Y7kw1ZXweK5XFazV8tPJ4N0715D4umkvdcj9Yf B+ATzxn2/Mw5hjfWFVO2T86Hzt728Yq+HTczYlVCtYvExIVToz2EscaMGtKLuRVZzUW4 Q+fpt6DXs1QYV9pKyz3Jwwi/pqh5OZUdX5Esy8WFnsWkLUwhi/oDr1L4HXMBFTM7cK9i GPRZjV2V3claKOC/17pXl5lgEgbg5TeDVADvKTZNfdRa+5BWDsIEwi+JiMrkGiqJsSqP DFZg== X-Gm-Message-State: AIkVDXIk5d1YgWV+rOgaympPusGs+POq+KQeDrQwaFI5QRfnCvciW4AlzlVssztvYfloN3OIjAVX6SkWDEog/Q== X-Received: by 10.200.53.247 with SMTP id l52mr24105215qtb.144.1485844142355; Mon, 30 Jan 2017 22:29:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 30 Jan 2017 22:29:01 -0800 (PST) From: Martin Thomson Date: Tue, 31 Jan 2017 17:29:01 +1100 Message-ID: Subject: Performance/safety trade-off To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 06:29:05 -0000 In PR #39, there is a choice: https://github.com/quicwg/base-drafts/pull/39 If a server receives 1-RTT-protected packets before it receives the client Finished message, it could use them. It has the keys. Obviously, if the server depends on certificate-based client authentication it will wait. But that's still a relatively rare occurrence. However, using 1-RTT data before verifying the Finished message could leave the server more vulnerable to an attack where the ClientHello is modified by an attacker. This is something that TLS 1.3 protects against, but only indirectly. The traffic keys are dependent on the content of the ClientHello and so it is likely that modifications of the ClientHello would result in being unable to communicate. But this isn't a strong assertion. The various forms of analysis of the TLS 1.3 handshake have all (I think) assumed that verification of the Finished message is what provides integrity for the handshake. In #39, I opted to forbid use of the client 1-RTT data until the handshake completes. I'd like to confirm that this is acceptable. In addition to confirming this, I'd like input on what level of justification is necessary for this in the document. If we believe that this is the right decision, do we need to do anything to prevent someone from pulling out a false start hack because they disagree with this analysis? From nobody Tue Jan 31 01:16: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 0D8D71204D9 for ; Tue, 31 Jan 2017 01:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 hmE6USzz6zop for ; Tue, 31 Jan 2017 01:16:38 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0E10C126D74 for ; Tue, 31 Jan 2017 01:16:38 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 0980C1B001B9; Tue, 31 Jan 2017 11:14:00 +0000 (GMT) Message-ID: <589055D5.5090008@erg.abdn.ac.uk> Date: Tue, 31 Jan 2017 09:16:05 +0000 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Martin Thomson Subject: Re: Ossification References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IETF QUIC WG , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-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, 31 Jan 2017 09:16:41 -0000 I see real merit in moving beyond (1) for another reason if this exposes at least connection ID, packet number, packet number echo (asuming one can also derive (begin/end of flow, etc for a traffic flow. Over the years I've seen the IETF produce quite a few "transport" protocols, and while each of them has had different requirements and ambitions, I'd like to observe that successful ones often include an ability for network operators and independent researchers to both gather per-flow traffic measurements and to understand pathologies of how traffic flows share capacity and understand where problems exist within networks. Doing this within the network relies on visibility of at least fields with visibility of basic flow information in the payload. It's OK fro me tohave rules about whether packet numbers have to monotomically increase to be useful at a receiver, whether receivers can usefully use re-resequenced packets, or data with gaps, etc. Even with these constraints, a set of visible fields could still open-up data on whether my current network link is seeing more "gaps", "resequencing", "whatever" compared to a measurement at another time of day, or another type of network link - all of which can be helpful in understanding how to operate my network, and whether this traffic is co-existing with other transport services. As we look ahead to networks with greater variability (5G?), more reordering, or wider mixes of traffic and forwarding rules, this becomes more important, not less. Gorry On 31/01/2017 00:35, Martin Thomson wrote: > On 31 January 2017 at 04:08, Mirja Kühlewind > wrote: >> - packet number (can be used for loss detection of losses that occurred before the observation point if increased linearly without gaps), and > On this point, existing implementations skip packet numbers > periodically. That looks like loss to the other side (or the path), > but even spurious losses don't have a bit impact on things like > congestion control if they are rare enough. > > One thing that we've discussed is the use of gaps to verify packet > receipt after a connection migration. An endpoint that detects a move > can start skipping more aggressively to protect against optimistic ack > attacks on that new path. I guess that you could argue that echoing a > packet number achieves the same effect more efficiently, but we would > need to assess that in the context of the bytes it would expend > overall. From nobody Tue Jan 31 07:19: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 947B2129999 for ; Tue, 31 Jan 2017 07:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 uv7iaJ5NSHRL for ; Tue, 31 Jan 2017 07:19:39 -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 47BCF12999E for ; Tue, 31 Jan 2017 07:19:38 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id w194so227290211ybe.0 for ; Tue, 31 Jan 2017 07:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jNnnFT0RL90V9T8scEs0wVwtvZBM+Qj7oDwGz3CHWQw=; b=CpYR0jih23yltlKaOKj+f5BezMuBbnVN+ok6ptNVfnDzum+AbOhxElImvyGTHtIVUf macAhmbujcRzMmTChs13Q8czzmbI2jvyVGzCAF51NQq2dYSPdJ3kRvXb2qUrLTEhtjWz +gVGNgUD6YuMJJ0cmc/DpvFXbYPRe0+KaGny8WnqS7kGSYM3trh7az1c/AUXJro2nH69 NhsLnrvW4KhRIkEPuEGvd/us+Ldw/W66Z/TnskgVaULffcSOm+IMWzr6NUom4f5J9RxO YBE1QCujjF6M+7w9rs3to6CEetn3buKow+6aEHvx0X9hqiJkH+Hy48ZbRcp+RI6HnWaJ MMhQ== 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=jNnnFT0RL90V9T8scEs0wVwtvZBM+Qj7oDwGz3CHWQw=; b=MnJFJJazXEuUszWucnWhIcI0SXJt9vKTVU2uxVqRj67Pnk1atHEsJK99tlut+KGh91 oiv3oWZ7v6LRpT1P9gmoFIUxrSdhGTDgc5PmyE6GcKhJ9T2nf2Y0o4AYEuxL7AztBbfL IPwJZuBPWLGPBnUPAtxFocV0aeLDwy4fs0C8X66rqho/HS4tB7OmJTCv+SM6+WnjGGFz vrSInPv4Rc54bnoHjVvwYXTJT9fhkYw3p+nmNywwS6Koa6dTHS46rNmC5QZwEp6SoRr6 6P35Fft6zwHWC5w6VL2asNcU8snfSTNjy197lhZuuDisqZedFtMP4vvsn7NQCPd/AN1+ QJkA== X-Gm-Message-State: AIkVDXKDmwtdwiw35DzPbvuf3vzEEAh+6Ip0H7I3ZxrDy7FkhJbfQCPqIkdKeXX0HVPoT4Kyyyc4fZQLMpY4Iy6O X-Received: by 10.37.86.215 with SMTP id k206mr15095989ybb.66.1485875977303; Tue, 31 Jan 2017 07:19:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Tue, 31 Jan 2017 07:19:16 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 31 Jan 2017 10:19:16 -0500 Message-ID: Subject: Re: Splitting QPACK To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a11425732cf197a05476575a6 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:19:40 -0000 --001a11425732cf197a05476575a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If the only reason to use 2 streams is to avoid framing, I think I'd rather have the framing and switch to 1 stream for headers and body, since compressed headers have framing associated with them anyway. My previous understanding was that two streams were used because the headers stream couldn't be cancelled, but putting all the table manipulations solves that. But there may be other reasons why 2 streams are preferable. On Mon, Jan 30, 2017 at 8:52 PM, Kazuho Oku wrote: > 2017-01-30 12:45 GMT+09:00 Mike Bishop : > > Yes, it would mean bringing back the DATA frame from HTTP/2. Given tha= t > we > > already have intra-stream framing (on one stream of two), that didn=E2= =80=99t > seem > > like a big loss to me. However, I can believe that there are performan= ce > > efficiencies to be gained from being able to dispense with framing once > you > > get to the body. > > My two cents go to using single stream for both headers and body, > since I'd be worried of the maximum amount of memory that would be > consumed by the per-stream receive windows. > > If we could send headers and body on a single stream then it would > mean that the maximum number of streams that an endpoint becomes half > when compared to current approach. That would in turn mean that the > maximum amount of memory that needs to be allocated for the receive > windows becomes half, or that the size of per-stream receive windows > can be doubled while keeping the maximum same to the current draft. > > > > > > > From: Ryan Hamilton [mailto:rch@google.com] > > Sent: Sunday, January 29, 2017 7:12 PM > > To: Mike Bishop > > Cc: IETF QUIC WG > > Subject: Re: Splitting QPACK > > > > > > > > > > > > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop < > Michael.Bishop@microsoft.com> > > wrote: > > > > Also, if we go this way, the remaining reasons to separate headers and > data > > seem to have disappeared, and we might be able to get down to one strea= m > per > > request. > > > > > > > > We'd still need some mechanism, within a stream, to delimit headers dat= a > > from body data, right? Using two QUIC streams solves this problem > nicely. I > > don't love adding more intra-stream framing, if we can avoid it. > > > > > > > > -- > Kazuho Oku > > --001a11425732cf197a05476575a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the only reason to use 2 streams is to avoid framing, I= think I'd rather have the framing and switch to 1 stream for headers a= nd body, since compressed headers have framing associated with them anyway.= =C2=A0 My previous understanding was that two streams were used because the= headers stream couldn't be cancelled, but putting all the table manipu= lations solves that.

But there may be other reasons why = 2 streams are preferable.

On Mon, Jan 30, 2017 at 8:52 PM, Kazuho Oku <kazuh= ooku@gmail.com> wrote:
2017-01-30 12:45 GMT+09:00 Mike Bishop <Michael.Bishop@microsoft.com>:
> Yes, it would mean bringing back the DATA frame from HTTP/2.=C2=A0 Giv= en that we
> already have intra-stream framing (on one stream of two), that didn=E2= =80=99t seem
> like a big loss to me.=C2=A0 However, I can believe that there are per= formance
> efficiencies to be gained from being able to dispense with framing onc= e you
> get to the body.

My two cents go to using single stream for both headers and body, since I'd be worried of the maximum amount of memory that would be
consumed by the per-stream receive windows.

If we could send headers and body on a single stream then it would
mean that the maximum number of streams that an endpoint becomes half
when compared to current approach. That would in turn mean that the
maximum amount of memory that needs to be allocated for the receive
windows becomes half, or that the size of per-stream receive windows
can be doubled while keeping the maximum same to the current draft.

>
>
> From: Ryan Hamilton [mailto:rch@goog= le.com]
> Sent: Sunday, January 29, 2017 7:12 PM
> To: Mike Bishop <Mi= chael.Bishop@microsoft.com>
> Cc: IETF QUIC WG <quic@ietf.org>
> Subject: Re: Splitting QPACK
>
>
>
>
>
> On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop <Michael.Bishop@microsoft.com>
> wrote:
>
> Also, if we go this way, the remaining reasons to separate headers and= data
> seem to have disappeared, and we might be able to get down to one stre= am per
> request.
>
>
>
> We'd still need some mechanism, within a stream, to delimit header= s data
> from body data, right? Using two QUIC streams solves this problem nice= ly. I
> don't love adding more intra-stream framing, if we can avoid it. >
>



--
Kazuho Oku


--001a11425732cf197a05476575a6-- From nobody Tue Jan 31 08:23: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 9A246129514 for ; Tue, 31 Jan 2017 08:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 tSiZJCItLwsX for ; Tue, 31 Jan 2017 08:23:02 -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 7F225129FA1 for ; Tue, 31 Jan 2017 08:23:02 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id 123so125709716ybe.3 for ; Tue, 31 Jan 2017 08:23:02 -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=ZddSietqRFghcuc3MpziodE0gXvmwjmgOq0MDeQXxsw=; b=S1/FoHp1GcqObrk8yxquPUI46NNH5fsBUtmGa3ySfYYFL6uwZoQY85e0Mk5YT4qgFl 9WuLOAfl9OklwQGvJc76Fh9054lQFlhS9+R1VKruWJD4pU8DoJSlBSuB4FuaqzH2IWCi x6t1PmXeBZK3WYP3NOoUEvnJFWD2XlgXKfWru2VTGXGWUyYjeVSqhsxr4uSCJq2Eda6/ OtlSfofxsXDjaQ3DjwSZfk9+oNuGky6SgLr8HxLYp/MWyjhLCWBqeHQCJHWFvURFEYDg qAT2JcXnJAI0Y2WhjyZKVRqDCoH3IEyWGw6HgMZsysYAQ/hNBwM4K189rmI+8i3xHasj Uk3w== 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=ZddSietqRFghcuc3MpziodE0gXvmwjmgOq0MDeQXxsw=; b=q/YQrom9o6c3B60WlU12hllkWcPRL85fgiFCciGjteZPofUKjayAx/wS1WOtPeJ6oE 10lpmfyj5rMrK9OVQC5GWHIV/c57ZKeteGWwdSispD2zO8ZYTCDAmqe0Lmu/96e0x7fg 8X+UgmP9EHymz+h276OT3vR0+f4BkP3nwu2NIK9sl+pzoSn5ZOSkqksm1JsEtJn4RmLh lgb9pLP5sNCbdMLHR1RIyWyWbjxqkpTdDnH97YKqNF4TlcTRGXENPFkP7QOPTFTN3cr5 DzMLhQJ2p0ANGjdX46nVtQ0zkMomT3grECaO5HnlkGTbYsBd+2+my5ZJBm2bNAia0Lhb 0dGw== X-Gm-Message-State: AIkVDXKJHUJjjIrDRszP84/mG+1j4f28odbcJ1H/ycTDTEVttzgM422twDIWtR48VQFESSmNs86EuM49aSPtLHEJ X-Received: by 10.37.170.114 with SMTP id s105mr6469062ybi.44.1485879781505; Tue, 31 Jan 2017 08:23:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Tue, 31 Jan 2017 08:22:41 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 31 Jan 2017 11:22:41 -0500 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114878748ec7180547665816 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:23:09 -0000 --001a114878748ec7180547665816 Content-Type: text/plain; charset=UTF-8 My intuition is that forbidding the server from processing 1RTT packets until the client finished message is received would be a very small impact on latency if it was just a matter of waiting for the re-transmission. However, if the server can't process those packets, it can't send an ack for them, and the ack would indicate the client finished message had been lost, which would speed up loss detection. So it seems like a bummer to not be able to process them. This would also mean the server couldn't process an ack for any 1RTT data the it sent, since that would be encrypted. On Tue, Jan 31, 2017 at 1:29 AM, Martin Thomson wrote: > In PR #39, there is a choice: > > https://github.com/quicwg/base-drafts/pull/39 > > If a server receives 1-RTT-protected packets before it receives the > client Finished message, it could use them. It has the keys. > > Obviously, if the server depends on certificate-based client > authentication it will wait. But that's still a relatively rare > occurrence. > > However, using 1-RTT data before verifying the Finished message could > leave the server more vulnerable to an attack where the ClientHello is > modified by an attacker. This is something that TLS 1.3 protects > against, but only indirectly. The traffic keys are dependent on the > content of the ClientHello and so it is likely that modifications of > the ClientHello would result in being unable to communicate. But this > isn't a strong assertion. The various forms of analysis of the TLS > 1.3 handshake have all (I think) assumed that verification of the > Finished message is what provides integrity for the handshake. > > In #39, I opted to forbid use of the client 1-RTT data until the > handshake completes. I'd like to confirm that this is acceptable. > > In addition to confirming this, I'd like input on what level of > justification is necessary for this in the document. If we believe > that this is the right decision, do we need to do anything to prevent > someone from pulling out a false start hack because they disagree with > this analysis? > > --001a114878748ec7180547665816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My intuition is that forbidding the server from processing= 1RTT packets until the client finished message is received would be a very= small impact on latency if it was just a matter of waiting for the re-tran= smission. =C2=A0 However, if the server can't process those packets, it= can't send an ack for them, and the ack would indicate the client fini= shed message had been lost, which would speed up loss detection.

So it seems like a bummer to not be able to process them.=C2=A0 Th= is would also mean the server couldn't process an ack for any 1RTT data= the it sent, since that would be encrypted.

On Tue, Jan 31, 2017 at 1:29 AM, Mar= tin Thomson <martin.thomson@gmail.com> wrote:
In PR #39, there is a choice:

https://github.com/quicwg/base-drafts/pull/39<= br>
If a server receives 1-RTT-protected packets before it receives the
client Finished message, it could use them.=C2=A0 It has the keys.

Obviously, if the server depends on certificate-based client
authentication it will wait.=C2=A0 But that's still a relatively rare occurrence.

However, using 1-RTT data before verifying the Finished message could
leave the server more vulnerable to an attack where the ClientHello is
modified by an attacker.=C2=A0 This is something that TLS 1.3 protects
against, but only indirectly.=C2=A0 The traffic keys are dependent on the content of the ClientHello and so it is likely that modifications of
the ClientHello would result in being unable to communicate.=C2=A0 But this=
isn't a strong assertion.=C2=A0 The various forms of analysis of the TL= S
1.3 handshake have all (I think) assumed that verification of the
Finished message is what provides integrity for the handshake.

In #39, I opted to forbid use of the client 1-RTT data until the
handshake completes.=C2=A0 I'd like to confirm that this is acceptable.=

In addition to confirming this, I'd like input on what level of
justification is necessary for this in the document.=C2=A0 If we believe that this is the right decision, do we need to do anything to prevent
someone from pulling out a false start hack because they disagree with
this analysis?


--001a114878748ec7180547665816-- From nobody Tue Jan 31 08:27: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 E41BE1299BD for ; Tue, 31 Jan 2017 08:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8bOaScA6YvH for ; Tue, 31 Jan 2017 08:27:05 -0800 (PST) Received: from mail-wj0-x229.google.com (mail-wj0-x229.google.com [IPv6:2a00:1450:400c:c01::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 121A6129421 for ; Tue, 31 Jan 2017 08:27:05 -0800 (PST) Received: by mail-wj0-x229.google.com with SMTP id n2so16674971wjq.3 for ; Tue, 31 Jan 2017 08:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KhMaw0gHZqy9Wcw3jwhdL0ukfH3HOJZnuX11VKC+2kE=; b=e+QjBsydGMYLQ6r7nC4PArqpmR67LsG5TQ0QoTNGMUdHM6VnT4EXl7CZXPyKgx3rEB EIV6nEB4Q/+2xMCRzDPLbvT4znUDGHOLJXtKcHV0QgGtHjKgREWDZ6Bch8Za0pIiHili hC5vhFbw5Ty5oUcJUmpRlUr8cGnvvo/GH6HCK1yJdftGNj8e2h/Agjauouza4yhG46h/ IyibIb8oXx6ap1G+hKAYqJNamY/Lu1PhBloCghSqiY+ZE9k+x8D6IxPQ6u0Lt1EZFyEx Gtt3jmvL2ynRFzO57htuyLFHUejmpeNzXIVcyQW5per63dXrCHqHo9z1s/3xs1Nb/YUG hoAg== 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=KhMaw0gHZqy9Wcw3jwhdL0ukfH3HOJZnuX11VKC+2kE=; b=dGy2ptqe+m8FlU7ybUALcnyrBLmzUv3NnYj47wFN5IO9cgygDmC16aU/FjtqwhIUku wTq+/GHWN8WHxw8qiRbc+TKAcYAi/6fYsMtMO9RdOAlpCZFgKZC0n+vap+MQAbPBS+KU shvxPN0dukLXAauo6v9GvhtZ2M2119VpLGt8XImDg/85mCXyOKjYgWaHGeX1bchwXov/ uYKlLdbE2PeiqnmWz50MhV2p0HdXjjzG99RIHa+g1xEt0j1EUyOUw6JqBgGCcucSIZQ0 tcG5DAdUbrpuEccWPdm+qUfGe/uFi4XuukfhTn8Umt+FM4/XIWBASDBpz4cvIYPu5KBM 7e7g== X-Gm-Message-State: AIkVDXLZfPpIVRUAHIReitxPgspqXxhj+JPcaqnTLJqVrqMXsqoeQ0tn6DDMZPJAwWjT/axnn4PAGn9yAb1yfw== X-Received: by 10.223.134.104 with SMTP id 37mr23435435wrw.121.1485880023494; Tue, 31 Jan 2017 08:27:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.130 with HTTP; Tue, 31 Jan 2017 08:27:02 -0800 (PST) In-Reply-To: References: From: Watson Ladd Date: Tue, 31 Jan 2017 08:27:02 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:27:10 -0000 On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson wrote: > In PR #39, there is a choice: > > https://github.com/quicwg/base-drafts/pull/39 > > If a server receives 1-RTT-protected packets before it receives the > client Finished message, it could use them. It has the keys. > > Obviously, if the server depends on certificate-based client > authentication it will wait. But that's still a relatively rare > occurrence. > > However, using 1-RTT data before verifying the Finished message could > leave the server more vulnerable to an attack where the ClientHello is > modified by an attacker. This is something that TLS 1.3 protects > against, but only indirectly. The traffic keys are dependent on the > content of the ClientHello and so it is likely that modifications of > the ClientHello would result in being unable to communicate. But this > isn't a strong assertion. The various forms of analysis of the TLS > 1.3 handshake have all (I think) assumed that verification of the > Finished message is what provides integrity for the handshake. I don't believe the finished message is necessary for ensuring manipulation of the client hello message is detected. > > In #39, I opted to forbid use of the client 1-RTT data until the > handshake completes. I'd like to confirm that this is acceptable. > > In addition to confirming this, I'd like input on what level of > justification is necessary for this in the document. If we believe > that this is the right decision, do we need to do anything to prevent > someone from pulling out a false start hack because they disagree with > this analysis? > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Jan 31 09:10: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 442251299BC for ; Tue, 31 Jan 2017 09:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 Vl6VdqWYfxoA for ; Tue, 31 Jan 2017 09:10:17 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339861299D5 for ; Tue, 31 Jan 2017 09:10:17 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id y9so279046358uae.2 for ; Tue, 31 Jan 2017 09:10:17 -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=pjFFuGVPSg/A3VY8rvBQF+Ef7dCspApafyUpgesmXqk=; b=P7MPzJjSgEvpQI8jH1KT/Hd22l4sIIV8bBrjbIekRohccGciFJWbF0J07RjMz0XKeh /DuZWOouzlNOhO07+5FcIJShHpQ6QsZtK6kcXQJDXyVXl/epKM4xuheG5m/ToOU2GE85 OOTrQbOu2kbolDz/8rKkUeenJZ9weOShT62I1gIY3ygZ0RyfER5kom4fkMdeP9xkT2Ay 1Vdt5I0Zegrxcv3QOtFuf1R1J1ds/C6T0xaZ0SpV8SssDXGORuDqLKM4aBzqxpLhbI2b 8UTTv6cwzmzkZuDbsc2VjvoWL6sWUdG5CkKM1Kd5qPyqfPHn2P4TNbcSlJEAaPQUoLIk DI6w== 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=pjFFuGVPSg/A3VY8rvBQF+Ef7dCspApafyUpgesmXqk=; b=e46HQNGRYzcWlaD4WrMghCefBddHExfTsle9xWNqbTpXLCj30BuIkFvirjr4kS3O5g otsx8fKoFKkl4p5nIjKMHIHqfqnRQ3X/4DMeVASioxYo8tsYo4xJwBBUTv9wwnDD9QdS JcWuyKe7ZLIBvzr3fc6+odLFbX0cBsk933Cdt2zZg9waHbWNMcoXcUjFnufGEpTHb5PF nlQ0uigQUl6JKA/7N5ImkszTT3dUHTZ+NE+eIoVn+5DyQjWmLqPS9VZDf4cJ6ADnWIzC oRFQ1rZTSu7AtpxP1zk7aEYZZ8CZS9+lankygir03ddwY2OUYAR8SMeVKzGR2fNmPxIw Opww== X-Gm-Message-State: AIkVDXJiHRcIT3qzxTOdsR0gV7+qEaKl869eD0seK+wLPga8cuvIkMGtk8hJAnWWCtMxaAjq13egDME3dmx90Nrx X-Received: by 10.159.48.79 with SMTP id i15mr12264070uab.13.1485882616004; Tue, 31 Jan 2017 09:10:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Tue, 31 Jan 2017 09:10:15 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 31 Jan 2017 09:10:15 -0800 Message-ID: Subject: Re: Splitting QPACK To: Ian Swett Content-Type: multipart/alternative; boundary=f403045d9e2282077305476701b7 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Ryan Hamilton , Kazuho Oku X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 31 Jan 2017 17:10:19 -0000 --f403045d9e2282077305476701b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Catching up slowly. Thanks for putting this together. I think I like the idea of simply using a stream where ordering is useful. Two points: - I like the Horizon idea, but I'm not convinced that the flexibility buys you much. In the simplest case, the encoder would simply state the last request that uses the entry, right? I would expect, in teh common case, that stating this number is sufficient. I understand that listing streams buys you space earlier in teh case of loss/reordering, but the added complexity seems high, and I'm generally concerned that implementations might get this wrong. - I don't understand why headers have to go in the same stream as data. The model you propose still allows for headers to go in a separate headers stream, while only table-manipulating entries go in the "QPACK" stream, right? The primary value of having headers go in a separate stream from the data was always to avoid framing. We will have to do gymnastics to get QPACK right across requests -- but if we assume that inserts and deletes are less common than references to the headers (as any reasonable compression algorithm should assume), then we should see things happen on the QPACK stream once in a while, and references occur more frequently on the request header streams. On Tue, Jan 31, 2017 at 7:19 AM, Ian Swett wrote: > If the only reason to use 2 streams is to avoid framing, I think I'd > rather have the framing and switch to 1 stream for headers and body, sinc= e > compressed headers have framing associated with them anyway. My previous > understanding was that two streams were used because the headers stream > couldn't be cancelled, but putting all the table manipulations solves tha= t. > > But there may be other reasons why 2 streams are preferable. > > On Mon, Jan 30, 2017 at 8:52 PM, Kazuho Oku wrote: > >> 2017-01-30 12:45 GMT+09:00 Mike Bishop : >> > Yes, it would mean bringing back the DATA frame from HTTP/2. Given >> that we >> > already have intra-stream framing (on one stream of two), that didn=E2= =80=99t >> seem >> > like a big loss to me. However, I can believe that there are >> performance >> > efficiencies to be gained from being able to dispense with framing onc= e >> you >> > get to the body. >> >> My two cents go to using single stream for both headers and body, >> since I'd be worried of the maximum amount of memory that would be >> consumed by the per-stream receive windows. >> >> If we could send headers and body on a single stream then it would >> mean that the maximum number of streams that an endpoint becomes half >> when compared to current approach. That would in turn mean that the >> maximum amount of memory that needs to be allocated for the receive >> windows becomes half, or that the size of per-stream receive windows >> can be doubled while keeping the maximum same to the current draft. >> >> > >> > >> > From: Ryan Hamilton [mailto:rch@google.com] >> > Sent: Sunday, January 29, 2017 7:12 PM >> > To: Mike Bishop >> > Cc: IETF QUIC WG >> > Subject: Re: Splitting QPACK >> > >> > >> > >> > >> > >> > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop < >> Michael.Bishop@microsoft.com> >> > wrote: >> > >> > Also, if we go this way, the remaining reasons to separate headers and >> data >> > seem to have disappeared, and we might be able to get down to one >> stream per >> > request. >> > >> > >> > >> > We'd still need some mechanism, within a stream, to delimit headers da= ta >> > from body data, right? Using two QUIC streams solves this problem >> nicely. I >> > don't love adding more intra-stream framing, if we can avoid it. >> > >> > >> >> >> >> -- >> Kazuho Oku >> >> > --f403045d9e2282077305476701b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Catching up slowly. Thanks for putting this together. I th= ink I like the idea of simply using a stream where ordering is useful. Two = points:
- I like the Horizon idea, but I'm not convinced that the f= lexibility buys you much. In the simplest case, the encoder would simply st= ate the last request that uses the entry, right? I would expect, in teh com= mon case, that stating this number is sufficient. I understand that listing= streams buys you space earlier in teh case of loss/reordering, but the add= ed complexity seems high, and I'm generally concerned that implementati= ons might get this wrong.
- I don't understand why headers ha= ve to go in the same stream as data. The model you propose still allows for= headers to go in a separate headers stream, while only table-manipulating = entries go in the "QPACK" stream, right? The primary value of hav= ing headers go in a separate stream from the data was always to avoid frami= ng. We will have to do gymnastics to get QPACK right across requests -- but= if we assume that inserts and deletes are less common than references to t= he headers (as any reasonable compression algorithm should assume), then we= should see things happen on the QPACK stream once in a while, and referenc= es occur more frequently on the request header streams.

On Tue, Jan 31, 2017 at 7= :19 AM, Ian Swett <ianswett@google.com> wrote:
If the only reason to use 2 streams= is to avoid framing, I think I'd rather have the framing and switch to= 1 stream for headers and body, since compressed headers have framing assoc= iated with them anyway.=C2=A0 My previous understanding was that two stream= s were used because the headers stream couldn't be cancelled, but putti= ng all the table manipulations solves that.

But there ma= y be other reasons why 2 streams are preferable.

On Mon, Jan 30, 2017 at 8:52 PM, Kazuho Oku <<= a href=3D"mailto:kazuhooku@gmail.com" target=3D"_blank">kazuhooku@gmail.com= > wrote:
2017-01-30 1= 2:45 GMT+09:00 Mike Bishop <Michael.Bishop@microsoft.com>:
> Yes, it would mean bringing back the DATA frame from HTTP/2.=C2=A0 Giv= en that we
> already have intra-stream framing (on one stream of two), that didn=E2= =80=99t seem
> like a big loss to me.=C2=A0 However, I can believe that there are per= formance
> efficiencies to be gained from being able to dispense with framing onc= e you
> get to the body.

My two cents go to using single stream for both headers and body, since I'd be worried of the maximum amount of memory that would be
consumed by the per-stream receive windows.

If we could send headers and body on a single stream then it would
mean that the maximum number of streams that an endpoint becomes half
when compared to current approach. That would in turn mean that the
maximum amount of memory that needs to be allocated for the receive
windows becomes half, or that the size of per-stream receive windows
can be doubled while keeping the maximum same to the current draft.

>
>
> From: Ryan Hamilton [mailto:rch@google.com]
> Sent: Sunday, January 29, 2017 7:12 PM
> To: Mike Bishop <Michael.Bishop@microsoft.com>
> Cc: IETF QUIC WG <quic@ietf.org>
> Subject: Re: Splitting QPACK
>
>
>
>
>
> On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop <Michael.Bishop@microsoft.com>
> wrote:
>
> Also, if we go this way, the remaining reasons to separate headers and= data
> seem to have disappeared, and we might be able to get down to one stre= am per
> request.
>
>
>
> We'd still need some mechanism, within a stream, to delimit header= s data
> from body data, right? Using two QUIC streams solves this problem nice= ly. I
> don't love adding more intra-stream framing, if we can avoid it. >
>



--
Kazuho Oku



--f403045d9e2282077305476701b7-- From nobody Tue Jan 31 09:17: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 EE4C012A00C for ; Tue, 31 Jan 2017 09:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 cTzIIFBNfh7I for ; Tue, 31 Jan 2017 09:17:22 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A9312A005 for ; Tue, 31 Jan 2017 09:17:21 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id i68so277236546uad.0 for ; Tue, 31 Jan 2017 09:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QGjhDoeiEs4g0Nodtp5hb/KSeScU4kiFSEf0//bYR5I=; b=ltF+fggw+9wY8WnfpWgJz4Hmk5iDn30xiCpHEkxRfy0rAB04SHF20NfUPTdchuQ5CH zwbYk5ic1qM09vhEdmx5XwCOLKg4kkWbgRMrWDW42lWLNtjcnOwnbTXxmKiwyW4Birzx /jwZrnmrsCYUq8yMBFwG9PjX++U8LQd87XgqXduooJSEA/Cox6hYY3+bFD7GN4R9B0Ow 19t9pKzrRyrxt8LHJgNLmbrmMOoRQKsE5YN91uTbqW2JZ/RBq7pM/VYabVgodCNUBcOP j0rr+0uh8bMvEdE3ddYn3QlGmsySq0gH0iA4xplAR9saPDWsNCajpV01ys/mr1XfqicX wrKw== 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=QGjhDoeiEs4g0Nodtp5hb/KSeScU4kiFSEf0//bYR5I=; b=lWqH+Z3fpMv04xEO4z70eC8B9rkRSanw5+IDtXmZqwgIbHfRGwjWEztqaZVk/+2l85 8HcuwkXe+oFp5ZXcOAcBL2Mker74JVabKTckEcjzC6Pjj6SdUC8pa3Ojoe/5kWE+LrY4 r2kmlsspSkJB5JYbjepGKZMGCEB0LcDosWnZj4wUnek3LzmIpuotHgXhhhfBShjyV4Rh zncVxLTwtjZt/aRVuV1Ytin/LQ93ALSQRrylq42SoyzVIpwCPLVVVf+MiG1USyFOc9pB 1lXi8cOVN+1SD0QD6qQUpSWg/4/iEFPLqY6kK9gTBqntRhpS+rYsH5xd1VYoj0b5uNSr /fNw== X-Gm-Message-State: AIkVDXI3axheNRU5AVCJb7UjkOdrGu78ERrVtIZcGcaoRwpCtI1rUqkbV5cV/3C+j+0h+Ein9MuDOfzJxcFrgJxj X-Received: by 10.176.1.119 with SMTP id 110mr12817750uak.143.1485883040800; Tue, 31 Jan 2017 09:17:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Tue, 31 Jan 2017 09:17:20 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 31 Jan 2017 09:17:20 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11466686d3d8920547671af6 Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 17:17:24 -0000 --001a11466686d3d8920547671af6 Content-Type: text/plain; charset=UTF-8 Since the keys cannot be the same if the ClientHello were to be modified, what is the risk we are talking about here? I don't know about the crypto analyses of the TLS handshake, so some insight here would be helpful. But I agree that having the server process 1-RTT data would help with loss detection. If there's no real security implication, I'd be in favor of letting the server process this data. On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd wrote: > On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson > wrote: > > In PR #39, there is a choice: > > > > https://github.com/quicwg/base-drafts/pull/39 > > > > If a server receives 1-RTT-protected packets before it receives the > > client Finished message, it could use them. It has the keys. > > > > Obviously, if the server depends on certificate-based client > > authentication it will wait. But that's still a relatively rare > > occurrence. > > > > However, using 1-RTT data before verifying the Finished message could > > leave the server more vulnerable to an attack where the ClientHello is > > modified by an attacker. This is something that TLS 1.3 protects > > against, but only indirectly. The traffic keys are dependent on the > > content of the ClientHello and so it is likely that modifications of > > the ClientHello would result in being unable to communicate. But this > > isn't a strong assertion. The various forms of analysis of the TLS > > 1.3 handshake have all (I think) assumed that verification of the > > Finished message is what provides integrity for the handshake. > > I don't believe the finished message is necessary for ensuring > manipulation of the client hello message is detected. > > > > In #39, I opted to forbid use of the client 1-RTT data until the > > handshake completes. I'd like to confirm that this is acceptable. > > > > In addition to confirming this, I'd like input on what level of > > justification is necessary for this in the document. If we believe > > that this is the right decision, do we need to do anything to prevent > > someone from pulling out a false start hack because they disagree with > > this analysis? > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > --001a11466686d3d8920547671af6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since the keys cannot be the same if the ClientHello were = to be modified, what is the risk we are talking about here? I don't kno= w about the crypto analyses of the TLS handshake, so some insight here woul= d be helpful. But I agree that having the server process 1-RTT data would h= elp with loss detection. If there's no real security implication, I'= ;d be in favor of letting the server process this data.

On Tue, Jan 31, 2017 at 8:27 AM= , Watson Ladd <watsonbladd@gmail.com> wrote:
On Mon, Jan 30, 2017 at 10:29 PM, M= artin Thomson
<martin.thomson@gmail.com> wrote:
> In PR #39, there is a choice:
>
> https://github.com/quicwg/base-drafts/pull/39=
>
> If a server receives 1-RTT-protected packets before it receives the > client Finished message, it could use them.=C2=A0 It has the keys.
>
> Obviously, if the server depends on certificate-based client
> authentication it will wait.=C2=A0 But that's still a relatively r= are
> occurrence.
>
> However, using 1-RTT data before verifying the Finished message could<= br> > leave the server more vulnerable to an attack where the ClientHello is=
> modified by an attacker.=C2=A0 This is something that TLS 1.3 protects=
> against, but only indirectly.=C2=A0 The traffic keys are dependent on = the
> content of the ClientHello and so it is likely that modifications of > the ClientHello would result in being unable to communicate.=C2=A0 But= this
> isn't a strong assertion.=C2=A0 The various forms of analysis of t= he TLS
> 1.3 handshake have all (I think) assumed that verification of the
> Finished message is what provides integrity for the handshake.

I don't believe the finished message is necessary for ensuring manipulation of the client hello message is detected.
>
> In #39, I opted to forbid use of the client 1-RTT data until the
> handshake completes.=C2=A0 I'd like to confirm that this is accept= able.
>
> In addition to confirming this, I'd like input on what level of > justification is necessary for this in the document.=C2=A0 If we belie= ve
> that this is the right decision, do we need to do anything to prevent<= br> > someone from pulling out a false start hack because they disagree with=
> this analysis?
>



--
"Man is born free, but everywhere he is in chains".
--Rousseau.


--001a11466686d3d8920547671af6-- From nobody Tue Jan 31 09:46: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 E3E2012955B for ; Tue, 31 Jan 2017 09:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 ovsgXbQP_Cug for ; Tue, 31 Jan 2017 09:46:51 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D83812953B for ; Tue, 31 Jan 2017 09:46:51 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id l66so137559501ioi.1 for ; Tue, 31 Jan 2017 09:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kse0SN5jomPbTFga5jO87D/VprHS/nh7nxM7RxMeH0A=; b=elXe7U3rwKSlheV5H7enO5UsNxpyJiL3PI+DUNBFjPwqoul5yUL6sngK9WkwqadaM3 VKSSHgHlvTAkXS2i/yF+cOXcusaHnR0uc6FEXpyC+lEZZeMh8B1OjDOBlLEnsBVEl7fW o9H0biEJDaY0hZcSWHVPPuTsO9JaGMzgPhasbBKzoqR+opmgVjwW8/EVwpzRbkCL1aIz vCWAJ7yyDOE7RSCZerHDNspvM9leENlmy9LqI8lW5K7toEyEwHN/JJBEKO01tTl1AF2b AOgGhJp5WIOKaJaa8mfpFO3/gfIDfzGhEXljX+omjKzq1crG37GWaMLE+BtbwGGybsW4 iiKQ== 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=kse0SN5jomPbTFga5jO87D/VprHS/nh7nxM7RxMeH0A=; b=h7egGRriVdMyIsyxcdybyznc2iF6ktbu2WdBdTYJtDj7rz0IcdlIR1VtS5THaNiCE2 72Sf3rnQzInNSMe+HATKlTSnCCPOWyN4FDcdh1+uyhszZRLXOHfGQPTBlZ2XqCJMk9vh ny4JcL1a2WQmFp6hvsa/yi8Y1jS0YDm5mlH4n/BsHkwj4MmmPlIy0wuBcRZyh+c5DDbO QXVRrGzPl2miY0km9q0xr8WaSoeCk7D59HG+Q73HmoalXccfWnmqBw3GOVllxwSXyZzW XKPxAzbvhMz48yp8I7wnpCTv1lnAfxrXtLR45WJQ1G2yR4/Sp6/56X+HpqeU1+7xBsQL ZJPw== X-Gm-Message-State: AIkVDXIpWevGU5LwEaM+ZL4t/4KC+sGdcbCBQKL6LFfZ97y3L1UuShsJfx4w5eThx1gIyfcS7fSJ/i+j8lblmH82 X-Received: by 10.107.34.10 with SMTP id i10mr23105467ioi.41.1485884810255; Tue, 31 Jan 2017 09:46:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.112 with HTTP; Tue, 31 Jan 2017 09:46:29 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Tue, 31 Jan 2017 09:46:29 -0800 Message-ID: Subject: Re: Splitting QPACK To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a1140ec684b702c0547678450 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 17:46:53 -0000 --001a1140ec684b702c0547678450 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2017 at 5:52 PM, Kazuho Oku wrote: > 2017-01-30 12:45 GMT+09:00 Mike Bishop : > > Yes, it would mean bringing back the DATA frame from HTTP/2. Given tha= t > we > > already have intra-stream framing (on one stream of two), that didn=E2= =80=99t > seem > > like a big loss to me. However, I can believe that there are performan= ce > > efficiencies to be gained from being able to dispense with framing once > you > > get to the body. > > My two cents go to using single stream for both headers and body, > since I'd be worried of the maximum amount of memory that would be > consumed by the per-stream receive windows. > > If we could send headers and body on a single stream then it would > mean that the maximum number of streams that an endpoint becomes half > when compared to current approach. That would in turn mean that the > maximum amount of memory that needs to be allocated for the receive > windows becomes half, or that the size of per-stream receive windows > can be doubled while keeping the maximum same to the current draft. > > When memory is a concern, I think an implementation should consider auto-tuning the receive window sizes. The Google QUIC code does this. Under such a regime, the total amount of memory used by receive buffers has more to do with aggregate BDP than number of streams. > > > > > From: Ryan Hamilton [mailto:rch@google.com] > > Sent: Sunday, January 29, 2017 7:12 PM > > To: Mike Bishop > > Cc: IETF QUIC WG > > Subject: Re: Splitting QPACK > > > > > > > > > > > > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop < > Michael.Bishop@microsoft.com> > > wrote: > > > > Also, if we go this way, the remaining reasons to separate headers and > data > > seem to have disappeared, and we might be able to get down to one strea= m > per > > request. > > > > > > > > We'd still need some mechanism, within a stream, to delimit headers dat= a > > from body data, right? Using two QUIC streams solves this problem > nicely. I > > don't love adding more intra-stream framing, if we can avoid it. > > > > > > > > -- > Kazuho Oku > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1140ec684b702c0547678450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 30, 2017 at 5:52 PM, Kazuho Oku <kazuhooku@gmail.com= > wrote:
2017-= 01-30 12:45 GMT+09:00 Mike Bishop <Michael.Bishop@microsoft.com>:
> Yes, it would mean bringing back the DATA frame from HTTP/2.=C2=A0 Giv= en that we
> already have intra-stream framing (on one stream of two), that didn=E2= =80=99t seem
> like a big loss to me.=C2=A0 However, I can believe that there are per= formance
> efficiencies to be gained from being able to dispense with framing onc= e you
> get to the body.

My two cents go to using single stream for both headers and body, since I'd be worried of the maximum amount of memory that would be
consumed by the per-stream receive windows.

If we could send headers and body on a single stream then it would
mean that the maximum number of streams that an endpoint becomes half
when compared to current approach. That would in turn mean that the
maximum amount of memory that needs to be allocated for the receive
windows becomes half, or that the size of per-stream receive windows
can be doubled while keeping the maximum same to the current draft.

W= hen memory is a concern, I think an implementation should consider auto-tun= ing the receive window sizes. =C2=A0 =C2=A0The Google QUIC code does this. = =C2=A0 =C2=A0 =C2=A0Under such a regime, the total amount of memory used by= receive buffers has more to do with aggregate BDP than number of streams.<= /div>

>
>
> From: Ryan Hamilton [mailto:rch@goog= le.com]
> Sent: Sunday, January 29, 2017 7:12 PM
> To: Mike Bishop <Mi= chael.Bishop@microsoft.com>
> Cc: IETF QUIC WG <quic@ietf.org>
> Subject: Re: Splitting QPACK
>
>
>
>
>
> On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop <Michael.Bishop@microsoft.com>
> wrote:
>
> Also, if we go this way, the remaining reasons to separate headers and= data
> seem to have disappeared, and we might be able to get down to one stre= am per
> request.
>
>
>
> We'd still need some mechanism, within a stream, to delimit header= s data
> from body data, right? Using two QUIC streams solves this problem nice= ly. I
> don't love adding more intra-stream framing, if we can avoid it. >
>



--
Kazuho Oku




--
= Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1

--001a1140ec684b702c0547678450-- From nobody Tue Jan 31 09:53: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 A217112953B for ; Tue, 31 Jan 2017 09:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 Wv_zOMAP8N_z for ; Tue, 31 Jan 2017 09:53:44 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0E112952B for ; Tue, 31 Jan 2017 09:53:44 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id j18so137452803ioe.2 for ; Tue, 31 Jan 2017 09:53:44 -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=ZHSmsZw6unfyDIMN09l/oHsj6T+TOjtY2wwYtGKTp6Y=; b=ASM7QkdRSDQeEOgEQSC7x0oZBnJBx7a+cs/+c1SaRoTkawvjiqI6sxyAd4dDZbx5Yv paoNpEitdPLU9pkpOBRF0Pwfhwg0xzpCDkTz/owlwqW3jetYD1/2CbkmNjzif6mWVl7F PVFxDF3ZxXK+qcmHzbHfHOnXf8yD65Er0LqD5+1srRT8BC0WNkxLdySMb+KnhrptWW+9 2HfN5m3pni/qxDIH1RIyh5UjLSirH1/Z+hFe72xa37sznGOuOGPNDWYTyzDDRbaSFeRE wX3uS2EmTJSCC48MEnozcn7OrKHKteFIt6iF+mtcOrvr7tzALviHBDW9fExT88fps3PC DRLQ== 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=ZHSmsZw6unfyDIMN09l/oHsj6T+TOjtY2wwYtGKTp6Y=; b=srQA1HlvzvqxTHldgIa4UTmauO9oo/8mshw/gkt1Sa/QCxMnsxNhOopkw/xP/RLhyP XXn3ZRAXm0WYw1TYZsRS6vf8VxESXcGBG5DPbW9M1HvsCaJT69cKlOHyGB01cp97yEwQ WgrC2e9xEVDQo+9gLHPSekn31w/+hFIcneYvDQvVzkjkLJSZpPeuTiMTgdCb24e5AuQz tTqN4CFjzfJXQhn0Foen9n4MsRUM7t5mmIWdVcbRWfBYDx+qw/VbL4+DLC4dbdrEsLa0 mqfuSgatPu1ASgKrCiC99ek8bK5ZOjtbOdVoDx5tFLeTmV4OSKolpkOAthrqLvY95lAE QQAQ== X-Gm-Message-State: AIkVDXKqHbAG1TRJcMw+UY/gAwGmaf7xWZGDNA0up8QnWOUcUd4oDKKZWsiLRR7hkbaEKIP6RPiofM1AcBawt8lK X-Received: by 10.107.26.205 with SMTP id a196mr24548072ioa.214.1485885223249; Tue, 31 Jan 2017 09:53:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.112 with HTTP; Tue, 31 Jan 2017 09:53:22 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Tue, 31 Jan 2017 09:53:22 -0800 Message-ID: Subject: Re: Splitting QPACK To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a113fd056e94d1c0547679c15 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 17:53:46 -0000 --001a113fd056e94d1c0547679c15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One more thought/question about a dedicated stream for updates. Would it penalize the compression of HoL avoiding further, in the sense that what would be an incremental update today would be an update on the control stream, along with a literal on the data stream? I.e. minimum two literals for most entries added to the table? On Tue, Jan 31, 2017 at 9:46 AM, Charles 'Buck' Krasic wrote: > > > On Mon, Jan 30, 2017 at 5:52 PM, Kazuho Oku wrote: > >> 2017-01-30 12:45 GMT+09:00 Mike Bishop : >> > Yes, it would mean bringing back the DATA frame from HTTP/2. Given >> that we >> > already have intra-stream framing (on one stream of two), that didn=E2= =80=99t >> seem >> > like a big loss to me. However, I can believe that there are >> performance >> > efficiencies to be gained from being able to dispense with framing onc= e >> you >> > get to the body. >> >> My two cents go to using single stream for both headers and body, >> since I'd be worried of the maximum amount of memory that would be >> consumed by the per-stream receive windows. >> >> If we could send headers and body on a single stream then it would >> mean that the maximum number of streams that an endpoint becomes half >> when compared to current approach. That would in turn mean that the >> maximum amount of memory that needs to be allocated for the receive >> windows becomes half, or that the size of per-stream receive windows >> can be doubled while keeping the maximum same to the current draft. >> >> When memory is a concern, I think an implementation should consider > auto-tuning the receive window sizes. The Google QUIC code does this. > Under such a regime, the total amount of memory used by receive buffer= s > has more to do with aggregate BDP than number of streams. > > > >> > >> > From: Ryan Hamilton [mailto:rch@google.com] >> > Sent: Sunday, January 29, 2017 7:12 PM >> > To: Mike Bishop >> > Cc: IETF QUIC WG >> > Subject: Re: Splitting QPACK >> > >> > >> > >> > >> > >> > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop < >> Michael.Bishop@microsoft.com> >> > wrote: >> > >> > Also, if we go this way, the remaining reasons to separate headers and >> data >> > seem to have disappeared, and we might be able to get down to one >> stream per >> > request. >> > >> > >> > >> > We'd still need some mechanism, within a stream, to delimit headers da= ta >> > from body data, right? Using two QUIC streams solves this problem >> nicely. I >> > don't love adding more intra-stream framing, if we can avoid it. >> > >> > >> >> >> >> -- >> Kazuho Oku >> >> > > > -- > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 <(408)%20412-1141> > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a113fd056e94d1c0547679c15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One more thought/question about a dedicated stream for upd= ates. =C2=A0 =C2=A0Would it penalize the compression of HoL avoiding furthe= r, in the sense that what would be an incremental update today would be an = update on the control stream, along with a literal on the data stream?=C2= =A0 I.e. minimum two literals for most entries added to the table?

On Tue, Jan 31, 2017= at 9:46 AM, Charles 'Buck' Krasic <ckrasic@google.com> wrote:


On Mon, = Jan 30, 2017 at 5:52 PM, Kazuho Oku <kazuhooku@gmail.com> = wrote:
2017-01-30 12:45 GMT+09:00 M= ike Bishop <Michael.Bishop@microsoft.com>:
> Yes, it would mean bringing back the DATA frame from HTTP/2.=C2=A0 Giv= en that we
> already have intra-stream framing (on one stream of two), that didn=E2= =80=99t seem
> like a big loss to me.=C2=A0 However, I can believe that there are per= formance
> efficiencies to be gained from being able to dispense with framing onc= e you
> get to the body.

My two cents go to using single stream for both headers and body, since I'd be worried of the maximum amount of memory that would be
consumed by the per-stream receive windows.

If we could send headers and body on a single stream then it would
mean that the maximum number of streams that an endpoint becomes half
when compared to current approach. That would in turn mean that the
maximum amount of memory that needs to be allocated for the receive
windows becomes half, or that the size of per-stream receive windows
can be doubled while keeping the maximum same to the current draft.

When memory is a concern,= I think an implementation should consider auto-tuning the receive window s= izes. =C2=A0 =C2=A0The Google QUIC code does this. =C2=A0 =C2=A0 =C2=A0Unde= r such a regime, the total amount of memory used by receive buffers has mor= e to do with aggregate BDP than number of streams.

>
>
> From: Ryan Hamilton [mailto:rch@google.com]
> Sent: Sunday, January 29, 2017 7:12 PM
> To: Mike Bishop <Michael.Bishop@microsoft.com>
> Cc: IETF QUIC WG <quic@ietf.org>
> Subject: Re: Splitting QPACK
>
>
>
>
>
> On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop <Michael.Bishop@microsoft.com>
> wrote:
>
> Also, if we go this way, the remaining reasons to separate headers and= data
> seem to have disappeared, and we might be able to get down to one stre= am per
> request.
>
>
>
> We'd still need some mechanism, within a stream, to delimit header= s data
> from body data, right? Using two QUIC streams solves this problem nice= ly. I
> don't love adding more intra-stream framing, if we can avoid it. >
>



--
Kazuho Oku




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




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

--001a113fd056e94d1c0547679c15-- From nobody Tue Jan 31 10:55: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 F08F2129562 for ; Tue, 31 Jan 2017 10:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 nGCF3_NA-06I for ; Tue, 31 Jan 2017 10:55:06 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C199D129551 for ; Tue, 31 Jan 2017 10:55:05 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id i68so279276877uad.0 for ; Tue, 31 Jan 2017 10:55:05 -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=asTqd+TKPb5kpRTIUIrs4h85W/xlJs8voQ4zx5dILjY=; b=gD++9lZ/qIIaFGHZ5/gBhHrUwwRxQxYam75TCll08bh0hmkzZ2u99/CLSx7S0JF6Wc vFppUJNfrTb3YaJfwWyA2dnVrroKOEEFj6RIyce5aFHikku+K2za/hbQ9RWIXgf+sW+L czW0NPtfwwk4ByMycjxMXRUwVV7SXDRHMeVD8UaIBpdLZr+KCKsmspdmYszENcxpGzC9 OiZmaftnmlugD+tbjqdxwfkfCIa3CN0D15y7DZ4tYcf5flKyhgcUTPs4eVakstW77lrM gVAvtAipYBDxCw5LFKn+MUvEZj28pgq640aqfgVC6A47luuRO529hfk7Vw1HcP2zBuzY cSEQ== 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=asTqd+TKPb5kpRTIUIrs4h85W/xlJs8voQ4zx5dILjY=; b=TrXEGd74HJtaCnGuZxVkllrumg34aZAIhzRBFRk2kdrkZjrWdLm2cRhGxvKErInGAo cvPZuhO8zKbgdE/DW9NKAqAq6o42HDsI7h/8cv21Dvv7R/bJ+s1dScNJCm5qvWP2y7DC 7LmbPOFhG/gZKq0wX4H7cmX/UwstQcyjUoL9hgQ43OtSd4O9HjJVoVzD3SlP4/K6ev0R x4R/t2Qb7KRxX/CpKhgTb/3H3zcDVU2qt1UYcgdbqL2LEXy1yKCa69ZREQWg2pijk2B/ bh0yGvQIFkXTPaXIPksJQ4s2Ni8XhdWcKHnG/oPMZmU9xGPxAI7BJ3YOjR/prJ4aZ9Tp ssTw== X-Gm-Message-State: AIkVDXKDHx089qw/HRdZlPhIfnD/qd9gCGuP76vpkhOnnSlKSLnPldJiQwkCAaIPeWDNn/EWK8/R85M+aOQtYnVN X-Received: by 10.176.83.153 with SMTP id k25mr12946399uaa.141.1485888904620; Tue, 31 Jan 2017 10:55:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Tue, 31 Jan 2017 10:55:04 -0800 (PST) In-Reply-To: <589055D5.5090008@erg.abdn.ac.uk> References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> From: Jana Iyengar Date: Tue, 31 Jan 2017 10:55:04 -0800 Message-ID: Subject: Re: Ossification To: "Gorry (erg)" Content-Type: multipart/alternative; boundary=f403045dd7ec5686570547687856 Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 18:55:08 -0000 --f403045dd7ec5686570547687856 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm loathe to increase the QUIC packet header size to avoid increasingly additional overhead. I agree that (1) seems fundamentally hard to do without substantial computational cost and other overhead, so I'd be fine with exposing some things. I think this is expected to be discussed in Chicago anyways, FWIW. That said, my expectation is that there are three types of middleboxes that we want to address: (i) Those that want to separate QUIC connections from unwarranted traffic; (ii) Those that want to track QUIC connection state; and (iii) Those that want to firewall certain services (eg., WebRTC). Middleboxes are interested in blocking services, not the transport. (iii) is basically solved using the same signals that middleboxes use today: server port number. Blocking UDP to port 443 effectively blocks use of QUIC for HTTPS. For (i) and (ii), if middleboxes are being modified to detect QUIC, I don't think they'd have trouble going through the state machine and remembering where the QUIC connection ID falls. I appreciate your concern about ossification of specific versions, but if there are ossified middleboxes that need to track connection state (type (iii) above), then we're stuck with the position of the connection ID anyways. Specifying the version or sending a magic number in each packet has quantifiable overhead cost but the benefits are unknown, and I'd be inclined against them. For in-network measurements, as we've discussed previously, there may be value in sending the "largest observed" in that header. On Tue, Jan 31, 2017 at 1:16 AM, Gorry Fairhurst wrote: > I see real merit in moving beyond (1) for another reason if this exposes > at least connection ID, packet number, packet number echo (asuming one ca= n > also derive (begin/end of flow, etc for a traffic flow. > > Over the years I've seen the IETF produce quite a few "transport" > protocols, and while each of them has had different requirements and > ambitions, I'd like to observe that successful ones often include an > ability for network operators and independent researchers to both gather > per-flow traffic measurements and to understand pathologies of how traffi= c > flows share capacity and understand where problems exist within networks. > Doing this within the network relies on visibility of at least fields wit= h > visibility of basic flow information in the payload. > > It's OK fro me tohave rules about whether packet numbers have to > monotomically increase to be useful at a receiver, whether receivers can > usefully use re-resequenced packets, or data with gaps, etc. Even with > these constraints, a set of visible fields could still open-up data on > whether my current network link is seeing more "gaps", "resequencing", > "whatever" compared to a measurement at another time of day, or another > type of network link - all of which can be helpful in understanding how t= o > operate my network, and whether this traffic is co-existing with other > transport services. As we look ahead to networks with greater variability > (5G?), more reordering, or wider mixes of traffic and forwarding rules, > this becomes more important, not less. > > Gorry > > > On 31/01/2017 00:35, Martin Thomson wrote: > >> On 31 January 2017 at 04:08, Mirja K=C3=BChlewind >> wrote: >> >>> - packet number (can be used for loss detection of losses that occurred >>> before the observation point if increased linearly without gaps), and >>> >> On this point, existing implementations skip packet numbers >> periodically. That looks like loss to the other side (or the path), >> but even spurious losses don't have a bit impact on things like >> congestion control if they are rare enough. >> >> One thing that we've discussed is the use of gaps to verify packet >> receipt after a connection migration. An endpoint that detects a move >> can start skipping more aggressively to protect against optimistic ack >> attacks on that new path. I guess that you could argue that echoing a >> packet number achieves the same effect more efficiently, but we would >> need to assess that in the context of the bytes it would expend >> overall. >> > > --f403045dd7ec5686570547687856 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm loathe to increase the QUIC packet header size to = avoid increasingly additional overhead. I agree that (1) seems fundamentall= y hard to do without substantial computational cost and other overhead, so = I'd be fine with exposing some things. I think this is expected to be d= iscussed in Chicago anyways, FWIW.

That said, my expecta= tion is that there are three types of middleboxes that we want to address:<= /div>
(i) Those that want to separate QUIC connections from unwarranted= traffic;
(ii) Those that want to track QUIC connection state; an= d
(iii) Those that want to firewall certain services (eg., WebRTC= ). Middleboxes are interested in blocking services, not the transport.

(iii) is basically solved using the same signals that = middleboxes use today: server port number. Blocking UDP to port 443 effecti= vely blocks use of QUIC for HTTPS.

For (i) and (ii= ), if middleboxes are being modified to detect QUIC, I don't think they= 'd have trouble going through the state machine and remembering where t= he QUIC connection ID falls. I appreciate your concern about ossification o= f specific versions, but if there are ossified middleboxes that need to tra= ck connection state (type (iii) above), then we're stuck with the posit= ion of the connection ID anyways.

Specifying the v= ersion or sending a magic number in each packet has quantifiable overhead c= ost but the benefits are unknown, and I'd be inclined against them. For= in-network measurements, as we've discussed previously, there may be v= alue in sending the "largest observed" in that header.

On Tue, Jan 31, = 2017 at 1:16 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> w= rote:
I see real merit in moving beyond (= 1) for another reason if this exposes at least connection ID, packet number= , packet number echo (asuming one can also derive (begin/end of flow, etc f= or a traffic flow.

Over the years I've seen the IETF produce quite a few "transport&q= uot; protocols, and while each of them has had different requirements and a= mbitions, I'd like to observe that successful ones often include an abi= lity for network operators and independent researchers to both gather per-f= low traffic measurements and to understand pathologies of how traffic flows= share capacity and understand where problems exist within networks. Doing = this within the network relies on visibility of at least fields with visibi= lity of basic flow information in the payload.

It's OK fro me tohave rules about whether packet numbers have to monoto= mically increase to be useful at a receiver, whether receivers can usefully= use re-resequenced packets, or data with gaps, etc. Even with these constr= aints, a set of visible fields could still open-up data on whether my curre= nt network link is seeing more "gaps", "resequencing", = "whatever" compared to a measurement at another time of day, or a= nother type of network link - all of which can be helpful in understanding = how to operate my network, and whether this traffic is co-existing with oth= er transport services. As we look ahead to networks with greater variabilit= y (5G?), more reordering, or wider mixes of traffic and forwarding rules, t= his becomes more important, not less.

Gorry


On 31/01/2017 00:35, Martin Thomson wrote:
On 31 January 2017 at 04:08, Mirja K=C3=BChlewind
<mi= rja.kuehlewind@tik.ee.ethz.ch>=C2=A0 wrote:
- packet number (can be used for loss detection of losses that occurred bef= ore the observation point if increased linearly without gaps), and
On this point, existing implementations skip packet numbers
periodically.=C2=A0 That looks like loss to the other side (or the path), but even spurious losses don't have a bit impact on things like
congestion control if they are rare enough.

One thing that we've discussed is the use of gaps to verify packet
receipt after a connection migration.=C2=A0 An endpoint that detects a move=
can start skipping more aggressively to protect against optimistic ack
attacks on that new path.=C2=A0 I guess that you could argue that echoing a=
packet number achieves the same effect more efficiently, but we would
need to assess that in the context of the bytes it would expend
overall.


--f403045dd7ec5686570547687856-- From nobody Tue Jan 31 10:56: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 37590129560 for ; Tue, 31 Jan 2017 10:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 DbuUPqXEqyp4 for ; Tue, 31 Jan 2017 10:56:46 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0050D1299A9 for ; Tue, 31 Jan 2017 10:56:42 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 1E0191B00055; Tue, 31 Jan 2017 20:54:10 +0000 (GMT) Message-ID: <5890DDCF.6010507@erg.abdn.ac.uk> Date: Tue, 31 Jan 2017 19:56:15 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: about draft-johansson-quic-ecn-00 References: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> In-Reply-To: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ingemar.s.johansson@ericsson.com" , quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-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, 31 Jan 2017 18:56:48 -0000 I'd also like to thank you for this consideration of where ECN fits within QUIC. I have a few comments, see below: I really do see merit in requiring implementation of the receiver functionality. This to me is independent of a decision whether to use the ECN functionality at the sender. I’d support it being mandatory to implement *at least* basic ECN receiver support (which I think is similar to what marcelo said). draft-ietf-tsvwg-rfc5405bis (now in RFC-ED queue), provides a checklist for UDP support for ECN, the current list in the draft seems similar, but is not quite the same. I think since rfc5405bis is scheduled for BCP, it would be good to cite this and align where possible. The decision whether a sender chooses to mark using ECT(0) or ECT(1) or neither needs to be based on understanding of whether the combined send and receive stacks and network devices currently provide support (or more likely measurement), monitoring as described in 2.6 (i.e., this is a per-path run-time decision). One thing a QUIC receiver may already know is whether a receive stack has support for ECN. I suggest this places requirements on the feedback method: A sender may need to understand how the network forwards ECT(x) marks on the forward path - (Alt 3 shows some functionality for this). this can confirm whether ECT(x) marks are received. I expect this will be needed to know that ECT and ECN-CE marks are actually being sent across the entire path, and are not cleared at some midpoint, erasing the congestion information. I think it is also would be useful to know that ECT(1) is actually traversing a path when using new ECT(1) semantics as described in the tsvwg draft (aka like L4S). I can see real advantages if alt-1, alt-2 at least provides a count to indicate the number of packets (bytes?) received with not-ECT; ECT(0); and ECT(1). Knowing receive code point information would also provide opportunities to detect and react appropriately to misbehaving receivers/paths (including sender control to set the mark value) - although at least while the path/receiver is being verified the sender will likely also be needed to know *which* packets carried a specific mark. (as noted alt-3 may not provide this). How we should do this, I am not sure - various ways exist - but designing a transport that can allow this should be possible. Gorry On 26/01/2017 10:40, marcelo bagnulo braun wrote: > Hi, > > I have read the draft and i think it is a good starting point for this > issue. thanks for writing it. > > My main comment is about the ECN negotiation. I am unconvinced that > the quic version negotiation is the right approach for this. > > I mean, afaiu, quic version negotiation imposes an extra RTT when the > new version is not supported. I think this is ok for major version > changes, but I dont think this is appropriate for feature negotiation > such as ECN. > > I mean, unless ECN is supported by default in the first quic version, > I think using quic version negotiation for ECN support would be an > obstacle in ECN adoption in quic. I mean, if we end up in the > situation that the first (widely deployed) quic protocol specification > does not support ECN by default, then having ECN negotiation using > quic version will imply that if a client wants to tries to see if the > server supports ECN, it risks to have a extra RTT penalty. (i > understand the client can cache which servers support ECN, but we are > back into working around these difficulties that make ecn adoption > harder). > > The other problem is related to the blocking of ECN bits in the IP > header. Ideally, I guess, the client should be able to learn if the > ECN bits are blocked during the negotiation phase i.e. the negotiation > can fail either because the server doesnt support it or because the > network doesnt support it. Because of this, I would argue that the > good approach is to have the ECN bits set in the IP header of the > packet carrying the ECN negotiation. > > So, with all this, I think it may be a better approach to make ECN > negotiation to be done using a new frame type that is sent in the > stream 1. This would be a message that the sender issues, after the > connection has been established, to request ECN support from the other > endpoint. This message would be sent in an ECN marked packet, to > verify that the network delivers the message. The other endpoint can > reply with another message accepting of not the ECN support for the > connection. > > I think this approach has the benefit of not imposing extra latency > for those who want to check if ECN is supported and at the same time > verifies that the network is able to deliver ECN marked packets. If > any of these conditions fail, the negotiation fail. Moreover, i think > these messages can be used to disable ECN in the middle of the > connection. One case where this can be useful is in a mobility > scenario, where one of the endpoints move and in order to check if the > new path still supports ECN, they can resend the option and see if the > packets still make it. I guess more complicated verification methods > could be built into this. > > thoughts? > > regards, marcelo > From nobody Tue Jan 31 11:24: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 E16A31299DB for ; Tue, 31 Jan 2017 11:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Vtbbk-3fmF8Y for ; Tue, 31 Jan 2017 11:24:33 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6C31299DC for ; Tue, 31 Jan 2017 11:24:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vCbmb46hQzMpbY; Tue, 31 Jan 2017 20:24:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH7AWC1DE6Q9; Tue, 31 Jan 2017 20:24:30 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC28DE.dip0.t-ipconnect.de [93.236.40.222]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 31 Jan 2017 20:24:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Ossification From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 31 Jan 2017 20:24:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> To: Jana Iyengar X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:24:36 -0000 Hi Jana, a few comments below. > Am 31.01.2017 um 19:55 schrieb Jana Iyengar : >=20 > I'm loathe to increase the QUIC packet header size to avoid = increasingly additional overhead. I agree that (1) seems fundamentally = hard to do without substantial computational cost and other overhead, so = I'd be fine with exposing some things. I think this is expected to be = discussed in Chicago anyways, FWIW. >=20 > That said, my expectation is that there are three types of middleboxes = that we want to address: > (i) Those that want to separate QUIC connections from unwarranted = traffic; > (ii) Those that want to track QUIC connection state; and > (iii) Those that want to firewall certain services (eg., WebRTC). = Middleboxes are interested in blocking services, not the transport. >=20 > (iii) is basically solved using the same signals that middleboxes use = today: server port number. Blocking UDP to port 443 effectively blocks = use of QUIC for HTTPS. >=20 > For (i) and (ii), if middleboxes are being modified to detect QUIC, I = don't think they'd have trouble going through the state machine and = remembering where the QUIC connection ID falls. I appreciate your = concern about ossification of specific versions, but if there are = ossified middleboxes that need to track connection state (type (iii) = above), then we're stuck with the position of the connection ID anyways. That=E2=80=99s my point. Knowing that the position of the connection ID = will ossify, we should maybe consider to actively decide that we want to = support that and design the protocol respectively. >=20 > Specifying the version or sending a magic number in each packet has = quantifiable overhead cost but the benefits are unknown, and I'd be = inclined against them. For in-network measurements, as we've discussed = previously, there may be value in sending the "largest observed" in that = header. We already agreed that having some kind of a magic number in the version = negotiation packets makes sense to avoid conflicts with other UDP = traffic. If you have seen version negotiation, you can use the = connection ID in subsequent packets to assign it to a known flow and = distinguish it from other UDP-based (cross) traffic. However, if you = have not seen the handshake, there is no way to distinguish UDP-based = quic traffic. This makes the quic handshake a special signal for the = network which I would rather like to avoid because it=E2=80=99s not. = Yes, putting a magic number in all packets is overhead. But this is the = trade-off I=E2=80=99d like to discuss. Mirja >=20 > On Tue, Jan 31, 2017 at 1:16 AM, Gorry Fairhurst = wrote: > I see real merit in moving beyond (1) for another reason if this = exposes at least connection ID, packet number, packet number echo = (asuming one can also derive (begin/end of flow, etc for a traffic flow. >=20 > Over the years I've seen the IETF produce quite a few "transport" = protocols, and while each of them has had different requirements and = ambitions, I'd like to observe that successful ones often include an = ability for network operators and independent researchers to both gather = per-flow traffic measurements and to understand pathologies of how = traffic flows share capacity and understand where problems exist within = networks. Doing this within the network relies on visibility of at least = fields with visibility of basic flow information in the payload. >=20 > It's OK fro me tohave rules about whether packet numbers have to = monotomically increase to be useful at a receiver, whether receivers can = usefully use re-resequenced packets, or data with gaps, etc. Even with = these constraints, a set of visible fields could still open-up data on = whether my current network link is seeing more "gaps", "resequencing", = "whatever" compared to a measurement at another time of day, or another = type of network link - all of which can be helpful in understanding how = to operate my network, and whether this traffic is co-existing with = other transport services. As we look ahead to networks with greater = variability (5G?), more reordering, or wider mixes of traffic and = forwarding rules, this becomes more important, not less. >=20 > Gorry >=20 >=20 > On 31/01/2017 00:35, Martin Thomson wrote: > On 31 January 2017 at 04:08, Mirja K=C3=BChlewind > wrote: > - packet number (can be used for loss detection of losses that = occurred before the observation point if increased linearly without = gaps), and > On this point, existing implementations skip packet numbers > periodically. That looks like loss to the other side (or the path), > but even spurious losses don't have a bit impact on things like > congestion control if they are rare enough. >=20 > One thing that we've discussed is the use of gaps to verify packet > receipt after a connection migration. An endpoint that detects a move > can start skipping more aggressively to protect against optimistic ack > attacks on that new path. I guess that you could argue that echoing a > packet number achieves the same effect more efficiently, but we would > need to assess that in the context of the bytes it would expend > overall. >=20 >=20 From nobody Tue Jan 31 11:37: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 70E401299A7 for ; Tue, 31 Jan 2017 11:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 xNY81Rqq439R for ; Tue, 31 Jan 2017 11:37:42 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE02129574 for ; Tue, 31 Jan 2017 11:37:42 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 96so280520072uaq.3 for ; Tue, 31 Jan 2017 11:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RH71APXGXumhZ1xoI3h2wU1B5h0AYE0xC94yvK7YhyI=; b=AxPnCGQMsDuxagw1uhq/KwhQdoSKMZsadQiJ2KvxEqHmiyHC2LXZGSsC1D0kpKxlHb c35gUG2JKMcFVmeNA12A6NIbPVveC3sPGMMnMWHYd+YU/cHncOkBtmKrmT3yxESmfF0m //hlWUNY93muqmWzzPzET0krmeFBUk0hYvHfnZvSG4CYMJ/SEJSRJz835fvI9yLE4huq 2NUs3sSp8mvY3mcMrPXKnKgt+aZW+SUOvLlCXIu1KWHRyhKgsuNCkT62t9Uv9AZReQ4K qfxunVKKNo8bXqv8XK01xGIP1gReZIot6uDWtnwg7w1zcsmLHQZj9Yq1PYqtiGjnwQaY 52HQ== 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=RH71APXGXumhZ1xoI3h2wU1B5h0AYE0xC94yvK7YhyI=; b=YxVsDEj0fXLYAZlH5Wn6cwvR+jwTDPtnec2/1TrWZz6EX1XsSCpGu/IiqUV3mIemX3 E8KHPZ5NcQCdq9L3VlfL5XvfZyzWqsnlDBQYxNCGwxTsW1Ws+hvlEh321I/ylpFIClOy /xk6L8SRE8fQAqTHwBZ7cH+528sEFSCbRwTEJMppZC3oqo96iSSaXzHSW5BFvTUAr5JO gIOVbZtbnMviViqHLSI5MDzkNuytBTA6sETql2/2bnA+amKSWtw0R2uGK1T8ZLqHeIXi tlCDV6IZJDia5X8le6HCzV9iVnwVw3UuKDBsljs4WMpPt+PMUp/Enpfu38hrvk5i5fb5 B3PQ== X-Gm-Message-State: AIkVDXJJYrs74W9INVP/f7W4GPgvDzjVHYePWyDcFIY2Ezm47YhcWRLlat94uG7FzDPIl95ZMTFt2cSP7j5wH5ag X-Received: by 10.176.83.153 with SMTP id k25mr13035862uaa.141.1485891461462; Tue, 31 Jan 2017 11:37:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Tue, 31 Jan 2017 11:37:41 -0800 (PST) In-Reply-To: <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> From: Jana Iyengar Date: Tue, 31 Jan 2017 11:37:41 -0800 Message-ID: Subject: Re: Ossification To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=f403045dd7ecbd3165054769101b Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:37:44 -0000 --f403045dd7ecbd3165054769101b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2017 at 11:24 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Jana, > > a few comments below. > > > Am 31.01.2017 um 19:55 schrieb Jana Iyengar : > > > > I'm loathe to increase the QUIC packet header size to avoid increasingl= y > additional overhead. I agree that (1) seems fundamentally hard to do > without substantial computational cost and other overhead, so I'd be fine > with exposing some things. I think this is expected to be discussed in > Chicago anyways, FWIW. > > > > That said, my expectation is that there are three types of middleboxes > that we want to address: > > (i) Those that want to separate QUIC connections from unwarranted > traffic; > > (ii) Those that want to track QUIC connection state; and > > (iii) Those that want to firewall certain services (eg., WebRTC). > Middleboxes are interested in blocking services, not the transport. > > > > (iii) is basically solved using the same signals that middleboxes use > today: server port number. Blocking UDP to port 443 effectively blocks us= e > of QUIC for HTTPS. > > > > For (i) and (ii), if middleboxes are being modified to detect QUIC, I > don't think they'd have trouble going through the state machine and > remembering where the QUIC connection ID falls. I appreciate your concern > about ossification of specific versions, but if there are ossified > middleboxes that need to track connection state (type (iii) above), then > we're stuck with the position of the connection ID anyways. > > That=E2=80=99s my point. Knowing that the position of the connection ID w= ill > ossify, we should maybe consider to actively decide that we want to suppo= rt > that and design the protocol respectively. I agree, and I think this should be discussed. > > > Specifying the version or sending a magic number in each packet has > quantifiable overhead cost but the benefits are unknown, and I'd be > inclined against them. For in-network measurements, as we've discussed > previously, there may be value in sending the "largest observed" in that > header. > > We already agreed that having some kind of a magic number in the version > negotiation packets makes sense to avoid conflicts with other UDP traffic= . > If you have seen version negotiation, you can use the connection ID in > subsequent packets to assign it to a known flow and distinguish it from > other UDP-based (cross) traffic. However, if you have not seen the > handshake, there is no way to distinguish UDP-based quic traffic. This > makes the quic handshake a special signal for the network which I would > rather like to avoid because it=E2=80=99s not. Yes, putting a magic numbe= r in all > packets is overhead. But this is the trade-off I=E2=80=99d like to discus= s. It is a special signal -- it is the beginning of a QUIC connection. I'm not sure why you would avoid that. If you're looking for a magic signal in every packet, I don't think it's going to be effective in the long term. It's simple enough for folks generating bogus traffic to send it with the magic signal. If you're trying to thwart redirected traffic, then you look for a handshake sequence, which gives you a pivot to hang the rest of the connection from. > > Mirja > > > > > > On Tue, Jan 31, 2017 at 1:16 AM, Gorry Fairhurst > wrote: > > I see real merit in moving beyond (1) for another reason if this expose= s > at least connection ID, packet number, packet number echo (asuming one ca= n > also derive (begin/end of flow, etc for a traffic flow. > > > > Over the years I've seen the IETF produce quite a few "transport" > protocols, and while each of them has had different requirements and > ambitions, I'd like to observe that successful ones often include an > ability for network operators and independent researchers to both gather > per-flow traffic measurements and to understand pathologies of how traffi= c > flows share capacity and understand where problems exist within networks. > Doing this within the network relies on visibility of at least fields wit= h > visibility of basic flow information in the payload. > > > > It's OK fro me tohave rules about whether packet numbers have to > monotomically increase to be useful at a receiver, whether receivers can > usefully use re-resequenced packets, or data with gaps, etc. Even with > these constraints, a set of visible fields could still open-up data on > whether my current network link is seeing more "gaps", "resequencing", > "whatever" compared to a measurement at another time of day, or another > type of network link - all of which can be helpful in understanding how t= o > operate my network, and whether this traffic is co-existing with other > transport services. As we look ahead to networks with greater variability > (5G?), more reordering, or wider mixes of traffic and forwarding rules, > this becomes more important, not less. > > > > Gorry > > > > > > On 31/01/2017 00:35, Martin Thomson wrote: > > On 31 January 2017 at 04:08, Mirja K=C3=BChlewind > > wrote: > > - packet number (can be used for loss detection of losses that occurred > before the observation point if increased linearly without gaps), and > > On this point, existing implementations skip packet numbers > > periodically. That looks like loss to the other side (or the path), > > but even spurious losses don't have a bit impact on things like > > congestion control if they are rare enough. > > > > One thing that we've discussed is the use of gaps to verify packet > > receipt after a connection migration. An endpoint that detects a move > > can start skipping more aggressively to protect against optimistic ack > > attacks on that new path. I guess that you could argue that echoing a > > packet number achieves the same effect more efficiently, but we would > > need to assess that in the context of the bytes it would expend > > overall. > > > > > > --f403045dd7ecbd3165054769101b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 31, 2017 at 11:24 AM, Mirja K=C3=BChlewind <= mirja.kuehlewind@tik.ee.ethz.ch> wrote:
Hi Jana,

a few comments below.

> Am 31.01.2017 um 19:55 schrieb Jana Iyengar <jri@google.com>:
>
> I'm loathe to increase the QUIC packet header size to avoid increa= singly additional overhead. I agree that (1) seems fundamentally hard to do= without substantial computational cost and other overhead, so I'd be f= ine with exposing some things. I think this is expected to be discussed in = Chicago anyways, FWIW.
>
> That said, my expectation is that there are three types of middleboxes= that we want to address:
> (i) Those that want to separate QUIC connections from unwarranted traf= fic;
> (ii) Those that want to track QUIC connection state; and
> (iii) Those that want to firewall certain services (eg., WebRTC). Midd= leboxes are interested in blocking services, not the transport.
>
> (iii) is basically solved using the same signals that middleboxes use = today: server port number. Blocking UDP to port 443 effectively blocks use = of QUIC for HTTPS.
>
> For (i) and (ii), if middleboxes are being modified to detect QUIC, I = don't think they'd have trouble going through the state machine and= remembering where the QUIC connection ID falls. I appreciate your concern = about ossification of specific versions, but if there are ossified middlebo= xes that need to track connection state (type (iii) above), then we're = stuck with the position of the connection ID anyways.

That=E2=80=99s my point. Knowing that the position of the connection= ID will ossify, we should maybe consider to actively decide that we want t= o support that and design the protocol respectively.

<= /div>
I agree, and I think this should be discussed.

>
> Specifying the version or sending a magic number in each packet has qu= antifiable overhead cost but the benefits are unknown, and I'd be incli= ned against them. For in-network measurements, as we've discussed previ= ously, there may be value in sending the "largest observed" in th= at header.

We already agreed that having some kind of a magic number in the ver= sion negotiation packets makes sense to avoid conflicts with other UDP traf= fic. If you have seen version negotiation, you can use the connection ID in= subsequent packets to assign it to a known flow and distinguish it from ot= her UDP-based (cross) traffic. However, if you have not seen the handshake,= there is no way to distinguish UDP-based quic traffic. This makes the quic= handshake a special signal for the network which I would rather like to av= oid because it=E2=80=99s not. Yes, putting a magic number in all packets is= overhead. But this is the trade-off I=E2=80=99d like to discuss.

It is a special signal -- it is the beginning of a Q= UIC connection. I'm not sure why you would avoid that.

If you're looking for a magic signal in every packet, I don= 9;t think it's going to be effective in the long term. It's simple = enough for folks generating bogus traffic to send it with the magic signal.= If you're trying to thwart redirected traffic, then you look for a han= dshake sequence, which gives you a pivot to hang the rest of the connection= from.

=C2=A0
=
Mirja


>
> On Tue, Jan 31, 2017 at 1:16 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> I see real merit in moving beyond (1) for another reason if this expos= es at least connection ID, packet number, packet number echo (asuming one c= an also derive (begin/end of flow, etc for a traffic flow.
>
> Over the years I've seen the IETF produce quite a few "transp= ort" protocols, and while each of them has had different requirements = and ambitions, I'd like to observe that successful ones often include a= n ability for network operators and independent researchers to both gather = per-flow traffic measurements and to understand pathologies of how traffic = flows share capacity and understand where problems exist within networks. D= oing this within the network relies on visibility of at least fields with v= isibility of basic flow information in the payload.
>
> It's OK fro me tohave rules about whether packet numbers have to m= onotomically increase to be useful at a receiver, whether receivers can use= fully use re-resequenced packets, or data with gaps, etc. Even with these c= onstraints, a set of visible fields could still open-up data on whether my = current network link is seeing more "gaps", "resequencing&qu= ot;, "whatever" compared to a measurement at another time of day,= or another type of network link - all of which can be helpful in understan= ding how to operate my network, and whether this traffic is co-existing wit= h other transport services. As we look ahead to networks with greater varia= bility (5G?), more reordering, or wider mixes of traffic and forwarding rul= es, this becomes more important, not less.
>
> Gorry
>
>
> On 31/01/2017 00:35, Martin Thomson wrote:
> On 31 January 2017 at 04:08, Mirja K=C3=BChlewind
> <mirja.kuehlewin= d@tik.ee.ethz.ch>=C2=A0 wrote:
> - packet number (can be used for loss detection of losses that occurre= d before the observation point if increased linearly without gaps), and
> On this point, existing implementations skip packet numbers
> periodically.=C2=A0 That looks like loss to the other side (or the pat= h),
> but even spurious losses don't have a bit impact on things like > congestion control if they are rare enough.
>
> One thing that we've discussed is the use of gaps to verify packet=
> receipt after a connection migration.=C2=A0 An endpoint that detects a= move
> can start skipping more aggressively to protect against optimistic ack=
> attacks on that new path.=C2=A0 I guess that you could argue that echo= ing a
> packet number achieves the same effect more efficiently, but we would<= br> > need to assess that in the context of the bytes it would expend
> overall.
>
>


--f403045dd7ecbd3165054769101b-- From nobody Tue Jan 31 11:59:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FFE129A10 for ; Tue, 31 Jan 2017 11:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffVozy5ktUfq for ; Tue, 31 Jan 2017 11:59:01 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0105.outbound.protection.outlook.com [104.47.36.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5307E129A07 for ; Tue, 31 Jan 2017 11:59:01 -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=QyiOZafcT/Ml5xzmoA2tPD+zcjE7fFZj8NCWdArDgTs=; b=btoD/5Hf9LF2BaQGZ2XwLE6JKwYzKLqK2tmwd0lQaVm6HwlGKp7F+Swr2WwlYKsu3Ru5fWotMR2dcBasUq5Ja6QfphJtYTjPM0G5ISFcvrakt+qxRfT6lqgjGvSC+SLSwQoUVfK3M5vxcksbM5t62kxrq8FhPmlwM8OFXhT60sk= Received: from CY4PR03MB2533.namprd03.prod.outlook.com (10.168.165.21) by CY4PR03MB2535.namprd03.prod.outlook.com (10.168.166.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 31 Jan 2017 19:58:58 +0000 Received: from CY4PR03MB2533.namprd03.prod.outlook.com ([10.168.165.21]) by CY4PR03MB2533.namprd03.prod.outlook.com ([10.168.165.21]) with mapi id 15.01.0860.026; Tue, 31 Jan 2017 19:58:58 +0000 From: Praveen Balasubramanian To: Jana Iyengar , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Ossification Thread-Topic: Ossification Thread-Index: AQHSext/oeEofLpKwEudNQ8G4u5lp6FRvaqAgACRa4CAAKHEAIAACDiAgAADsICAAAJw8A== Date: Tue, 31 Jan 2017 19:58:58 +0000 Message-ID: References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:a::616] x-ms-office365-filtering-correlation-id: 57c60816-5ae3-4990-161c-08d44a13985f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401078); SRVR:CY4PR03MB2535; x-microsoft-exchange-diagnostics: 1; CY4PR03MB2535; 7:BHJ77l9ZENvvH9aykB6hIZWkr8IJZYVpfVqLtnmOW1R5inmKbsS0a0WDJOZO7fglqV0mVd/3Sgq/uoeheOt3iSL6WM9qGfktTgmczwCqDOYcJN0NF4Lj3eVtvJz8NyyVPkAx9rwbLIlkE23fPYpCaRREGiKH+CzB0yJv6rfekt0j0PkYLBSxB/rlQyUBrokPBAq7Y3fVaInfMcmi7jH4ILHOKPgtJx7JomWqe5ukv98XQcLbe/zHqilmerE22y1R/vcYEq3uQcF48crjz7MfiU/NfCiUA/4jT5MESz77KnsUYGBsPtuC/9167DpEQRkguv0T+PVbAUqYIGh3FV3UfWGLkkkt2cx8JtxDTsdhdGCTcm+a2XUIod2U+pvLmS54ZZAu9W1mm11bYnn7s49P27DLuOan2y26jwfQe6jh8qbp8HYsbBLjDz/hkbT8hVjriqORHQ1ZdqDtsUq9vU2zf3UyHAKIbtm5k4o8YFTxWM2OW0hcKGF9+wG7diRObAUeufkEV0iGKDFP6Ql+vZ0rcgjv4VIaUd3ZdyIXPIlZNYEzsUpmnlxrfjJQYn4aJwjj x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(6047074); SRVR:CY4PR03MB2535; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2535; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(377454003)(24454002)(199003)(189002)(53936002)(189998001)(122556002)(7736002)(5005710100001)(54896002)(93886004)(2900100001)(74316002)(92566002)(38730400001)(221733001)(7696004)(99286003)(77096006)(68736007)(9686003)(6306002)(5660300001)(55016002)(2950100002)(25786008)(3280700002)(6506006)(7116003)(229853002)(39060400001)(54906002)(6436002)(2906002)(4326007)(106116001)(86362001)(105586002)(6116002)(8936002)(790700001)(101416001)(33656002)(97736004)(86612001)(10090500001)(5001770100001)(81166006)(8676002)(10290500002)(50986999)(8990500004)(76176999)(81156014)(3480700004)(54356999)(102836003)(236005)(3660700001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2535; H:CY4PR03MB2533.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR03MB2533AC0E1A2E46169AB89443B64A0CY4PR03MB2533namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 19:58:58.5273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2535 Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:59:04 -0000 --_000_CY4PR03MB2533AC0E1A2E46169AB89443B64A0CY4PR03MB2533namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIGF0IGxlYXN0IHRoZSBjb25uZWN0aW9uIElEIG11c3QgYmUgaW4gdGhlIGNsZWFyIGZvciBs b2FkIGJhbGFuY2luZyBwdXJwb3NlcyAtIGJvdGggaW4gdGhlIG5ldHdvcmsgZm9yIEVDTVAgYW5k IGluIHRoZSBlbmQgaG9zdCBmb3Igc3ByZWFkaW5nIHRyYWZmaWMgYW1vbmdzdCBjb3Jlcy4gRXNz ZW50aWFsbHkgSSBkb27igJl0IHRoaW5rIHdlIGNhbiBhc3N1bWUgdGhhdCBhbGwgbWlkZGxlYm94 ZXMgd2lsbCBiZSBzdGF0ZWZ1bCBvciB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gbmVlZCBmb3Igc3Rh dGVsZXNzIG9mZmxvYWRzIHRvIHRoZSBOSUNzLiBBbmQgZm9yIHN1Y2ggdXNlIGNhc2VzIGJlaW5n IGFibGUgdG8gZGlzdGluZ3Vpc2ggUVVJQyB0cmFmZmljIGlzIHZlcnkgdXNlZnVsIHRvIGF2b2lk IGZvciBleGFtcGxlIHNwcmVhZGluZyBvdGhlciBVRFAgdHJhZmZpYyBjYXVzaW5nIHBhY2tldCBy ZW9yZGVyaW5nIGFuZCByZWFzc2VtYmx5IGV0Yy4gU28gSSB0aGluayBhIG1hZ2ljIG51bWJlciBp cyB1c2VmdWwgbm90IG9ubHkgdG8gZGlzdGluZ3Vpc2ggUVVJQyBhbmQgUVVJQyB2ZXJzaW9ucyBi dXQgYWxzbyB0byBkaXN0aW5ndWlzaCBvdGhlciBVRFAgdHJhZmZpYy4gQnV0IHN1Y2ggYSBnZW5l cmljIG1lY2hhbmlzbSBmb3IgVURQIGlzIHByZXN1bWFibHkgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyB3b3JraW5nIGdyb3VwPw0KDQoNCg0KVGhhbmtzDQoNCkZyb206IFFVSUMgW21haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMzEsIDIwMTcgMTE6MzggQU0NClRvOiBNaXJqYSBLw7xobGV3aW5kIDxt aXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KQ2M6IEdvcnJ5IChlcmcpIDxnb3JyeUBl cmcuYWJkbi5hYy51az47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9t c29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogT3NzaWZpY2F0aW9u DQoNCg0KDQpPbiBUdWUsIEphbiAzMSwgMjAxNyBhdCAxMToyNCBBTSwgTWlyamEgS8O8aGxld2lu ZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEua3VlaGxld2lu ZEB0aWsuZWUuZXRoei5jaD4+IHdyb3RlOg0KSGkgSmFuYSwNCg0KYSBmZXcgY29tbWVudHMgYmVs b3cuDQoNCj4gQW0gMzEuMDEuMjAxNyB1bSAxOTo1NSBzY2hyaWViIEphbmEgSXllbmdhciA8anJp QGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPj46DQo+DQo+IEknbSBsb2F0aGUgdG8g aW5jcmVhc2UgdGhlIFFVSUMgcGFja2V0IGhlYWRlciBzaXplIHRvIGF2b2lkIGluY3JlYXNpbmds eSBhZGRpdGlvbmFsIG92ZXJoZWFkLiBJIGFncmVlIHRoYXQgKDEpIHNlZW1zIGZ1bmRhbWVudGFs bHkgaGFyZCB0byBkbyB3aXRob3V0IHN1YnN0YW50aWFsIGNvbXB1dGF0aW9uYWwgY29zdCBhbmQg b3RoZXIgb3ZlcmhlYWQsIHNvIEknZCBiZSBmaW5lIHdpdGggZXhwb3Npbmcgc29tZSB0aGluZ3Mu IEkgdGhpbmsgdGhpcyBpcyBleHBlY3RlZCB0byBiZSBkaXNjdXNzZWQgaW4gQ2hpY2FnbyBhbnl3 YXlzLCBGV0lXLg0KPg0KPiBUaGF0IHNhaWQsIG15IGV4cGVjdGF0aW9uIGlzIHRoYXQgdGhlcmUg YXJlIHRocmVlIHR5cGVzIG9mIG1pZGRsZWJveGVzIHRoYXQgd2Ugd2FudCB0byBhZGRyZXNzOg0K PiAoaSkgVGhvc2UgdGhhdCB3YW50IHRvIHNlcGFyYXRlIFFVSUMgY29ubmVjdGlvbnMgZnJvbSB1 bndhcnJhbnRlZCB0cmFmZmljOw0KPiAoaWkpIFRob3NlIHRoYXQgd2FudCB0byB0cmFjayBRVUlD IGNvbm5lY3Rpb24gc3RhdGU7IGFuZA0KPiAoaWlpKSBUaG9zZSB0aGF0IHdhbnQgdG8gZmlyZXdh bGwgY2VydGFpbiBzZXJ2aWNlcyAoZWcuLCBXZWJSVEMpLiBNaWRkbGVib3hlcyBhcmUgaW50ZXJl c3RlZCBpbiBibG9ja2luZyBzZXJ2aWNlcywgbm90IHRoZSB0cmFuc3BvcnQuDQo+DQo+IChpaWkp IGlzIGJhc2ljYWxseSBzb2x2ZWQgdXNpbmcgdGhlIHNhbWUgc2lnbmFscyB0aGF0IG1pZGRsZWJv eGVzIHVzZSB0b2RheTogc2VydmVyIHBvcnQgbnVtYmVyLiBCbG9ja2luZyBVRFAgdG8gcG9ydCA0 NDMgZWZmZWN0aXZlbHkgYmxvY2tzIHVzZSBvZiBRVUlDIGZvciBIVFRQUy4NCj4NCj4gRm9yIChp KSBhbmQgKGlpKSwgaWYgbWlkZGxlYm94ZXMgYXJlIGJlaW5nIG1vZGlmaWVkIHRvIGRldGVjdCBR VUlDLCBJIGRvbid0IHRoaW5rIHRoZXknZCBoYXZlIHRyb3VibGUgZ29pbmcgdGhyb3VnaCB0aGUg c3RhdGUgbWFjaGluZSBhbmQgcmVtZW1iZXJpbmcgd2hlcmUgdGhlIFFVSUMgY29ubmVjdGlvbiBJ RCBmYWxscy4gSSBhcHByZWNpYXRlIHlvdXIgY29uY2VybiBhYm91dCBvc3NpZmljYXRpb24gb2Yg c3BlY2lmaWMgdmVyc2lvbnMsIGJ1dCBpZiB0aGVyZSBhcmUgb3NzaWZpZWQgbWlkZGxlYm94ZXMg dGhhdCBuZWVkIHRvIHRyYWNrIGNvbm5lY3Rpb24gc3RhdGUgKHR5cGUgKGlpaSkgYWJvdmUpLCB0 aGVuIHdlJ3JlIHN0dWNrIHdpdGggdGhlIHBvc2l0aW9uIG9mIHRoZSBjb25uZWN0aW9uIElEIGFu eXdheXMuDQoNClRoYXTigJlzIG15IHBvaW50LiBLbm93aW5nIHRoYXQgdGhlIHBvc2l0aW9uIG9m IHRoZSBjb25uZWN0aW9uIElEIHdpbGwgb3NzaWZ5LCB3ZSBzaG91bGQgbWF5YmUgY29uc2lkZXIg dG8gYWN0aXZlbHkgZGVjaWRlIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0IHRoYXQgYW5kIGRlc2ln biB0aGUgcHJvdG9jb2wgcmVzcGVjdGl2ZWx5Lg0KDQpJIGFncmVlLCBhbmQgSSB0aGluayB0aGlz IHNob3VsZCBiZSBkaXNjdXNzZWQuDQoNCj4NCj4gU3BlY2lmeWluZyB0aGUgdmVyc2lvbiBvciBz ZW5kaW5nIGEgbWFnaWMgbnVtYmVyIGluIGVhY2ggcGFja2V0IGhhcyBxdWFudGlmaWFibGUgb3Zl cmhlYWQgY29zdCBidXQgdGhlIGJlbmVmaXRzIGFyZSB1bmtub3duLCBhbmQgSSdkIGJlIGluY2xp bmVkIGFnYWluc3QgdGhlbS4gRm9yIGluLW5ldHdvcmsgbWVhc3VyZW1lbnRzLCBhcyB3ZSd2ZSBk aXNjdXNzZWQgcHJldmlvdXNseSwgdGhlcmUgbWF5IGJlIHZhbHVlIGluIHNlbmRpbmcgdGhlICJs YXJnZXN0IG9ic2VydmVkIiBpbiB0aGF0IGhlYWRlci4NCg0KV2UgYWxyZWFkeSBhZ3JlZWQgdGhh dCBoYXZpbmcgc29tZSBraW5kIG9mIGEgbWFnaWMgbnVtYmVyIGluIHRoZSB2ZXJzaW9uIG5lZ290 aWF0aW9uIHBhY2tldHMgbWFrZXMgc2Vuc2UgdG8gYXZvaWQgY29uZmxpY3RzIHdpdGggb3RoZXIg VURQIHRyYWZmaWMuIElmIHlvdSBoYXZlIHNlZW4gdmVyc2lvbiBuZWdvdGlhdGlvbiwgeW91IGNh biB1c2UgdGhlIGNvbm5lY3Rpb24gSUQgaW4gc3Vic2VxdWVudCBwYWNrZXRzIHRvIGFzc2lnbiBp dCB0byBhIGtub3duIGZsb3cgYW5kIGRpc3Rpbmd1aXNoIGl0IGZyb20gb3RoZXIgVURQLWJhc2Vk IChjcm9zcykgdHJhZmZpYy4gSG93ZXZlciwgaWYgeW91IGhhdmUgbm90IHNlZW4gdGhlIGhhbmRz aGFrZSwgdGhlcmUgaXMgbm8gd2F5IHRvIGRpc3Rpbmd1aXNoIFVEUC1iYXNlZCBxdWljIHRyYWZm aWMuIFRoaXMgbWFrZXMgdGhlIHF1aWMgaGFuZHNoYWtlIGEgc3BlY2lhbCBzaWduYWwgZm9yIHRo ZSBuZXR3b3JrIHdoaWNoIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gYXZvaWQgYmVjYXVzZSBpdOKA mXMgbm90LiBZZXMsIHB1dHRpbmcgYSBtYWdpYyBudW1iZXIgaW4gYWxsIHBhY2tldHMgaXMgb3Zl cmhlYWQuIEJ1dCB0aGlzIGlzIHRoZSB0cmFkZS1vZmYgSeKAmWQgbGlrZSB0byBkaXNjdXNzLg0K DQpJdCBpcyBhIHNwZWNpYWwgc2lnbmFsIC0tIGl0IGlzIHRoZSBiZWdpbm5pbmcgb2YgYSBRVUlD IGNvbm5lY3Rpb24uIEknbSBub3Qgc3VyZSB3aHkgeW91IHdvdWxkIGF2b2lkIHRoYXQuDQoNCklm IHlvdSdyZSBsb29raW5nIGZvciBhIG1hZ2ljIHNpZ25hbCBpbiBldmVyeSBwYWNrZXQsIEkgZG9u J3QgdGhpbmsgaXQncyBnb2luZyB0byBiZSBlZmZlY3RpdmUgaW4gdGhlIGxvbmcgdGVybS4gSXQn cyBzaW1wbGUgZW5vdWdoIGZvciBmb2xrcyBnZW5lcmF0aW5nIGJvZ3VzIHRyYWZmaWMgdG8gc2Vu ZCBpdCB3aXRoIHRoZSBtYWdpYyBzaWduYWwuIElmIHlvdSdyZSB0cnlpbmcgdG8gdGh3YXJ0IHJl ZGlyZWN0ZWQgdHJhZmZpYywgdGhlbiB5b3UgbG9vayBmb3IgYSBoYW5kc2hha2Ugc2VxdWVuY2Us IHdoaWNoIGdpdmVzIHlvdSBhIHBpdm90IHRvIGhhbmcgdGhlIHJlc3Qgb2YgdGhlIGNvbm5lY3Rp b24gZnJvbS4NCg0KDQoNCk1pcmphDQoNCg0KPg0KPiBPbiBUdWUsIEphbiAzMSwgMjAxNyBhdCAx OjE2IEFNLCBHb3JyeSBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3Jy eUBlcmcuYWJkbi5hYy51az4+IHdyb3RlOg0KPiBJIHNlZSByZWFsIG1lcml0IGluIG1vdmluZyBi ZXlvbmQgKDEpIGZvciBhbm90aGVyIHJlYXNvbiBpZiB0aGlzIGV4cG9zZXMgYXQgbGVhc3QgY29u bmVjdGlvbiBJRCwgcGFja2V0IG51bWJlciwgcGFja2V0IG51bWJlciBlY2hvIChhc3VtaW5nIG9u ZSBjYW4gYWxzbyBkZXJpdmUgKGJlZ2luL2VuZCBvZiBmbG93LCBldGMgZm9yIGEgdHJhZmZpYyBm bG93Lg0KPg0KPiBPdmVyIHRoZSB5ZWFycyBJJ3ZlIHNlZW4gdGhlIElFVEYgcHJvZHVjZSBxdWl0 ZSBhIGZldyAidHJhbnNwb3J0IiBwcm90b2NvbHMsIGFuZCB3aGlsZSBlYWNoIG9mIHRoZW0gaGFz IGhhZCBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIGFuZCBhbWJpdGlvbnMsIEknZCBsaWtlIHRvIG9i c2VydmUgdGhhdCBzdWNjZXNzZnVsIG9uZXMgb2Z0ZW4gaW5jbHVkZSBhbiBhYmlsaXR5IGZvciBu ZXR3b3JrIG9wZXJhdG9ycyBhbmQgaW5kZXBlbmRlbnQgcmVzZWFyY2hlcnMgdG8gYm90aCBnYXRo ZXIgcGVyLWZsb3cgdHJhZmZpYyBtZWFzdXJlbWVudHMgYW5kIHRvIHVuZGVyc3RhbmQgcGF0aG9s b2dpZXMgb2YgaG93IHRyYWZmaWMgZmxvd3Mgc2hhcmUgY2FwYWNpdHkgYW5kIHVuZGVyc3RhbmQg d2hlcmUgcHJvYmxlbXMgZXhpc3Qgd2l0aGluIG5ldHdvcmtzLiBEb2luZyB0aGlzIHdpdGhpbiB0 aGUgbmV0d29yayByZWxpZXMgb24gdmlzaWJpbGl0eSBvZiBhdCBsZWFzdCBmaWVsZHMgd2l0aCB2 aXNpYmlsaXR5IG9mIGJhc2ljIGZsb3cgaW5mb3JtYXRpb24gaW4gdGhlIHBheWxvYWQuDQo+DQo+ IEl0J3MgT0sgZnJvIG1lIHRvaGF2ZSBydWxlcyBhYm91dCB3aGV0aGVyIHBhY2tldCBudW1iZXJz IGhhdmUgdG8gbW9ub3RvbWljYWxseSBpbmNyZWFzZSB0byBiZSB1c2VmdWwgYXQgYSByZWNlaXZl ciwgd2hldGhlciByZWNlaXZlcnMgY2FuIHVzZWZ1bGx5IHVzZSByZS1yZXNlcXVlbmNlZCBwYWNr ZXRzLCBvciBkYXRhIHdpdGggZ2FwcywgZXRjLiBFdmVuIHdpdGggdGhlc2UgY29uc3RyYWludHMs IGEgc2V0IG9mIHZpc2libGUgZmllbGRzIGNvdWxkIHN0aWxsIG9wZW4tdXAgZGF0YSBvbiB3aGV0 aGVyIG15IGN1cnJlbnQgbmV0d29yayBsaW5rIGlzIHNlZWluZyBtb3JlICJnYXBzIiwgInJlc2Vx dWVuY2luZyIsICJ3aGF0ZXZlciIgY29tcGFyZWQgdG8gYSBtZWFzdXJlbWVudCBhdCBhbm90aGVy IHRpbWUgb2YgZGF5LCBvciBhbm90aGVyIHR5cGUgb2YgbmV0d29yayBsaW5rIC0gYWxsIG9mIHdo aWNoIGNhbiBiZSBoZWxwZnVsIGluIHVuZGVyc3RhbmRpbmcgaG93IHRvIG9wZXJhdGUgbXkgbmV0 d29yaywgYW5kIHdoZXRoZXIgdGhpcyB0cmFmZmljIGlzIGNvLWV4aXN0aW5nIHdpdGggb3RoZXIg dHJhbnNwb3J0IHNlcnZpY2VzLiBBcyB3ZSBsb29rIGFoZWFkIHRvIG5ldHdvcmtzIHdpdGggZ3Jl YXRlciB2YXJpYWJpbGl0eSAoNUc/KSwgbW9yZSByZW9yZGVyaW5nLCBvciB3aWRlciBtaXhlcyBv ZiB0cmFmZmljIGFuZCBmb3J3YXJkaW5nIHJ1bGVzLCB0aGlzIGJlY29tZXMgbW9yZSBpbXBvcnRh bnQsIG5vdCBsZXNzLg0KPg0KPiBHb3JyeQ0KPg0KPg0KPiBPbiAzMS8wMS8yMDE3IDAwOjM1LCBN YXJ0aW4gVGhvbXNvbiB3cm90ZToNCj4gT24gMzEgSmFudWFyeSAyMDE3IGF0IDA0OjA4LCBNaXJq YSBLw7xobGV3aW5kDQo+IDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1haWx0bzpt aXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPj4gIHdyb3RlOg0KPiAtIHBhY2tldCBudW1i ZXIgKGNhbiBiZSB1c2VkIGZvciBsb3NzIGRldGVjdGlvbiBvZiBsb3NzZXMgdGhhdCBvY2N1cnJl ZCBiZWZvcmUgdGhlIG9ic2VydmF0aW9uIHBvaW50IGlmIGluY3JlYXNlZCBsaW5lYXJseSB3aXRo b3V0IGdhcHMpLCBhbmQNCj4gT24gdGhpcyBwb2ludCwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25z IHNraXAgcGFja2V0IG51bWJlcnMNCj4gcGVyaW9kaWNhbGx5LiAgVGhhdCBsb29rcyBsaWtlIGxv c3MgdG8gdGhlIG90aGVyIHNpZGUgKG9yIHRoZSBwYXRoKSwNCj4gYnV0IGV2ZW4gc3B1cmlvdXMg bG9zc2VzIGRvbid0IGhhdmUgYSBiaXQgaW1wYWN0IG9uIHRoaW5ncyBsaWtlDQo+IGNvbmdlc3Rp b24gY29udHJvbCBpZiB0aGV5IGFyZSByYXJlIGVub3VnaC4NCj4NCj4gT25lIHRoaW5nIHRoYXQg d2UndmUgZGlzY3Vzc2VkIGlzIHRoZSB1c2Ugb2YgZ2FwcyB0byB2ZXJpZnkgcGFja2V0DQo+IHJl Y2VpcHQgYWZ0ZXIgYSBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gIEFuIGVuZHBvaW50IHRoYXQgZGV0 ZWN0cyBhIG1vdmUNCj4gY2FuIHN0YXJ0IHNraXBwaW5nIG1vcmUgYWdncmVzc2l2ZWx5IHRvIHBy b3RlY3QgYWdhaW5zdCBvcHRpbWlzdGljIGFjaw0KPiBhdHRhY2tzIG9uIHRoYXQgbmV3IHBhdGgu ICBJIGd1ZXNzIHRoYXQgeW91IGNvdWxkIGFyZ3VlIHRoYXQgZWNob2luZyBhDQo+IHBhY2tldCBu dW1iZXIgYWNoaWV2ZXMgdGhlIHNhbWUgZWZmZWN0IG1vcmUgZWZmaWNpZW50bHksIGJ1dCB3ZSB3 b3VsZA0KPiBuZWVkIHRvIGFzc2VzcyB0aGF0IGluIHRoZSBjb250ZXh0IG9mIHRoZSBieXRlcyBp dCB3b3VsZCBleHBlbmQNCj4gb3ZlcmFsbC4NCj4NCj4NCg0K --_000_CY4PR03MB2533AC0E1A2E46169AB89443B64A0CY4PR03MB2533namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5o b2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlllcyBhdCBsZWFzdCB0aGUgY29ubmVjdGlvbiBJRCBtdXN0 IGJlIGluIHRoZSBjbGVhciBmb3IgbG9hZCBiYWxhbmNpbmcgcHVycG9zZXMgLSBib3RoIGluIHRo ZSBuZXR3b3JrIGZvciBFQ01QIGFuZCBpbiB0aGUgZW5kIGhvc3QgZm9yIHNwcmVhZGluZyB0cmFm ZmljIGFtb25nc3QgY29yZXMuIEVzc2VudGlhbGx5IEkgZG9u4oCZdCB0aGluayB3ZSBjYW4gYXNz dW1lIHRoYXQgYWxsIG1pZGRsZWJveGVzIHdpbGwNCiBiZSBzdGF0ZWZ1bCBvciB0aGF0IHRoZXJl IHdpbGwgYmUgbm8gbmVlZCBmb3Igc3RhdGVsZXNzIG9mZmxvYWRzIHRvIHRoZSBOSUNzLiBBbmQg Zm9yIHN1Y2ggdXNlIGNhc2VzIGJlaW5nIGFibGUgdG8gZGlzdGluZ3Vpc2ggUVVJQyB0cmFmZmlj IGlzIHZlcnkgdXNlZnVsIHRvIGF2b2lkIGZvciBleGFtcGxlIHNwcmVhZGluZyBvdGhlciBVRFAg dHJhZmZpYyBjYXVzaW5nIHBhY2tldCByZW9yZGVyaW5nIGFuZCByZWFzc2VtYmx5IGV0Yy4gU28g SSB0aGluaw0KIGEgbWFnaWMgbnVtYmVyIGlzIHVzZWZ1bCBub3Qgb25seSB0byBkaXN0aW5ndWlz aCBRVUlDIGFuZCBRVUlDIHZlcnNpb25zIGJ1dCBhbHNvIHRvIGRpc3Rpbmd1aXNoIG90aGVyIFVE UCB0cmFmZmljLiBCdXQgc3VjaCBhIGdlbmVyaWMgbWVjaGFuaXNtIGZvciBVRFAgaXMgcHJlc3Vt YWJseSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHdvcmtpbmcgZ3JvdXA/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9m DQo8L2I+SmFuYSBJeWVuZ2FyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMzEs IDIwMTcgMTE6MzggQU08YnI+DQo8Yj5Ubzo8L2I+IE1pcmphIEvDvGhsZXdpbmQgJmx0O21pcmph Lmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBHb3JyeSAoZXJn KSAmbHQ7Z29ycnlAZXJnLmFiZG4uYWMudWsmZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0 Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogT3NzaWZpY2F0aW9uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUdWUsIEphbiAzMSwgMjAxNyBhdCAxMToyNCBBTSwgTWlyamEgS8O8aGxld2luZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2giIHRhcmdldD0i X2JsYW5rIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEphbmEsPGJyPg0KPGJyPg0KYSBmZXcgY29t bWVudHMgYmVsb3cuPGJyPg0KPGJyPg0KJmd0OyBBbSAzMS4wMS4yMDE3IHVtIDE5OjU1IHNjaHJp ZWIgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBn b29nbGUuY29tPC9hPiZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgSSdtIGxvYXRoZSB0byBpbmNy ZWFzZSB0aGUgUVVJQyBwYWNrZXQgaGVhZGVyIHNpemUgdG8gYXZvaWQgaW5jcmVhc2luZ2x5IGFk ZGl0aW9uYWwgb3ZlcmhlYWQuIEkgYWdyZWUgdGhhdCAoMSkgc2VlbXMgZnVuZGFtZW50YWxseSBo YXJkIHRvIGRvIHdpdGhvdXQgc3Vic3RhbnRpYWwgY29tcHV0YXRpb25hbCBjb3N0IGFuZCBvdGhl ciBvdmVyaGVhZCwgc28gSSdkIGJlIGZpbmUgd2l0aCBleHBvc2luZyBzb21lIHRoaW5ncy4gSSB0 aGluayB0aGlzDQogaXMgZXhwZWN0ZWQgdG8gYmUgZGlzY3Vzc2VkIGluIENoaWNhZ28gYW55d2F5 cywgRldJVy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGF0IHNhaWQsIG15IGV4cGVjdGF0aW9uIGlz IHRoYXQgdGhlcmUgYXJlIHRocmVlIHR5cGVzIG9mIG1pZGRsZWJveGVzIHRoYXQgd2Ugd2FudCB0 byBhZGRyZXNzOjxicj4NCiZndDsgKGkpIFRob3NlIHRoYXQgd2FudCB0byBzZXBhcmF0ZSBRVUlD IGNvbm5lY3Rpb25zIGZyb20gdW53YXJyYW50ZWQgdHJhZmZpYzs8YnI+DQomZ3Q7IChpaSkgVGhv c2UgdGhhdCB3YW50IHRvIHRyYWNrIFFVSUMgY29ubmVjdGlvbiBzdGF0ZTsgYW5kPGJyPg0KJmd0 OyAoaWlpKSBUaG9zZSB0aGF0IHdhbnQgdG8gZmlyZXdhbGwgY2VydGFpbiBzZXJ2aWNlcyAoZWcu LCBXZWJSVEMpLiBNaWRkbGVib3hlcyBhcmUgaW50ZXJlc3RlZCBpbiBibG9ja2luZyBzZXJ2aWNl cywgbm90IHRoZSB0cmFuc3BvcnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgKGlpaSkgaXMgYmFzaWNh bGx5IHNvbHZlZCB1c2luZyB0aGUgc2FtZSBzaWduYWxzIHRoYXQgbWlkZGxlYm94ZXMgdXNlIHRv ZGF5OiBzZXJ2ZXIgcG9ydCBudW1iZXIuIEJsb2NraW5nIFVEUCB0byBwb3J0IDQ0MyBlZmZlY3Rp dmVseSBibG9ja3MgdXNlIG9mIFFVSUMgZm9yIEhUVFBTLjxicj4NCiZndDs8YnI+DQomZ3Q7IEZv ciAoaSkgYW5kIChpaSksIGlmIG1pZGRsZWJveGVzIGFyZSBiZWluZyBtb2RpZmllZCB0byBkZXRl Y3QgUVVJQywgSSBkb24ndCB0aGluayB0aGV5J2QgaGF2ZSB0cm91YmxlIGdvaW5nIHRocm91Z2gg dGhlIHN0YXRlIG1hY2hpbmUgYW5kIHJlbWVtYmVyaW5nIHdoZXJlIHRoZSBRVUlDIGNvbm5lY3Rp b24gSUQgZmFsbHMuIEkgYXBwcmVjaWF0ZSB5b3VyIGNvbmNlcm4gYWJvdXQgb3NzaWZpY2F0aW9u IG9mIHNwZWNpZmljIHZlcnNpb25zLCBidXQNCiBpZiB0aGVyZSBhcmUgb3NzaWZpZWQgbWlkZGxl Ym94ZXMgdGhhdCBuZWVkIHRvIHRyYWNrIGNvbm5lY3Rpb24gc3RhdGUgKHR5cGUgKGlpaSkgYWJv dmUpLCB0aGVuIHdlJ3JlIHN0dWNrIHdpdGggdGhlIHBvc2l0aW9uIG9mIHRoZSBjb25uZWN0aW9u IElEIGFueXdheXMuPGJyPg0KPGJyPg0KVGhhdOKAmXMgbXkgcG9pbnQuIEtub3dpbmcgdGhhdCB0 aGUgcG9zaXRpb24gb2YgdGhlIGNvbm5lY3Rpb24gSUQgd2lsbCBvc3NpZnksIHdlIHNob3VsZCBt YXliZSBjb25zaWRlciB0byBhY3RpdmVseSBkZWNpZGUgdGhhdCB3ZSB3YW50IHRvIHN1cHBvcnQg dGhhdCBhbmQgZGVzaWduIHRoZSBwcm90b2NvbCByZXNwZWN0aXZlbHkuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlLCBh bmQgSSB0aGluayB0aGlzIHNob3VsZCBiZSBkaXNjdXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PGJyPg0KJmd0OyBTcGVjaWZ5aW5nIHRoZSB2ZXJzaW9u IG9yIHNlbmRpbmcgYSBtYWdpYyBudW1iZXIgaW4gZWFjaCBwYWNrZXQgaGFzIHF1YW50aWZpYWJs ZSBvdmVyaGVhZCBjb3N0IGJ1dCB0aGUgYmVuZWZpdHMgYXJlIHVua25vd24sIGFuZCBJJ2QgYmUg aW5jbGluZWQgYWdhaW5zdCB0aGVtLiBGb3IgaW4tbmV0d29yayBtZWFzdXJlbWVudHMsIGFzIHdl J3ZlIGRpc2N1c3NlZCBwcmV2aW91c2x5LCB0aGVyZSBtYXkgYmUgdmFsdWUgaW4gc2VuZGluZyB0 aGUgJnF1b3Q7bGFyZ2VzdA0KIG9ic2VydmVkJnF1b3Q7IGluIHRoYXQgaGVhZGVyLjxicj4NCjxi cj4NCldlIGFscmVhZHkgYWdyZWVkIHRoYXQgaGF2aW5nIHNvbWUga2luZCBvZiBhIG1hZ2ljIG51 bWJlciBpbiB0aGUgdmVyc2lvbiBuZWdvdGlhdGlvbiBwYWNrZXRzIG1ha2VzIHNlbnNlIHRvIGF2 b2lkIGNvbmZsaWN0cyB3aXRoIG90aGVyIFVEUCB0cmFmZmljLiBJZiB5b3UgaGF2ZSBzZWVuIHZl cnNpb24gbmVnb3RpYXRpb24sIHlvdSBjYW4gdXNlIHRoZSBjb25uZWN0aW9uIElEIGluIHN1YnNl cXVlbnQgcGFja2V0cyB0byBhc3NpZ24gaXQgdG8gYSBrbm93bg0KIGZsb3cgYW5kIGRpc3Rpbmd1 aXNoIGl0IGZyb20gb3RoZXIgVURQLWJhc2VkIChjcm9zcykgdHJhZmZpYy4gSG93ZXZlciwgaWYg eW91IGhhdmUgbm90IHNlZW4gdGhlIGhhbmRzaGFrZSwgdGhlcmUgaXMgbm8gd2F5IHRvIGRpc3Rp bmd1aXNoIFVEUC1iYXNlZCBxdWljIHRyYWZmaWMuIFRoaXMgbWFrZXMgdGhlIHF1aWMgaGFuZHNo YWtlIGEgc3BlY2lhbCBzaWduYWwgZm9yIHRoZSBuZXR3b3JrIHdoaWNoIEkgd291bGQgcmF0aGVy IGxpa2UgdG8gYXZvaWQNCiBiZWNhdXNlIGl04oCZcyBub3QuIFllcywgcHV0dGluZyBhIG1hZ2lj IG51bWJlciBpbiBhbGwgcGFja2V0cyBpcyBvdmVyaGVhZC4gQnV0IHRoaXMgaXMgdGhlIHRyYWRl LW9mZiBJ4oCZZCBsaWtlIHRvIGRpc2N1c3MuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBhIHNwZWNpYWwgc2lnbmFsIC0t IGl0IGlzIHRoZSBiZWdpbm5pbmcgb2YgYSBRVUlDIGNvbm5lY3Rpb24uIEknbSBub3Qgc3VyZSB3 aHkgeW91IHdvdWxkIGF2b2lkIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSdyZSBsb29raW5nIGZvciBhIG1hZ2ljIHNpZ25h bCBpbiBldmVyeSBwYWNrZXQsIEkgZG9uJ3QgdGhpbmsgaXQncyBnb2luZyB0byBiZSBlZmZlY3Rp dmUgaW4gdGhlIGxvbmcgdGVybS4gSXQncyBzaW1wbGUgZW5vdWdoIGZvciBmb2xrcyBnZW5lcmF0 aW5nIGJvZ3VzIHRyYWZmaWMgdG8gc2VuZCBpdCB3aXRoIHRoZSBtYWdpYyBzaWduYWwuIElmIHlv dSdyZSB0cnlpbmcgdG8gdGh3YXJ0IHJlZGlyZWN0ZWQNCiB0cmFmZmljLCB0aGVuIHlvdSBsb29r IGZvciBhIGhhbmRzaGFrZSBzZXF1ZW5jZSwgd2hpY2ggZ2l2ZXMgeW91IGEgcGl2b3QgdG8gaGFu ZyB0aGUgcmVzdCBvZiB0aGUgY29ubmVjdGlvbiBmcm9tLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNw YW4gY2xhc3M9ImhvZW56YiI+TWlyamE8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFR1ZSwgSmFuIDMxLCAyMDE3IGF0IDE6 MTYgQU0sIEdvcnJ5IEZhaXJodXJzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRu LmFjLnVrIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSSBz ZWUgcmVhbCBtZXJpdCBpbiBtb3ZpbmcgYmV5b25kICgxKSBmb3IgYW5vdGhlciByZWFzb24gaWYg dGhpcyBleHBvc2VzIGF0IGxlYXN0IGNvbm5lY3Rpb24gSUQsIHBhY2tldCBudW1iZXIsIHBhY2tl dCBudW1iZXIgZWNobyAoYXN1bWluZyBvbmUgY2FuIGFsc28gZGVyaXZlIChiZWdpbi9lbmQgb2Yg ZmxvdywgZXRjIGZvciBhIHRyYWZmaWMgZmxvdy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPdmVyIHRo ZSB5ZWFycyBJJ3ZlIHNlZW4gdGhlIElFVEYgcHJvZHVjZSBxdWl0ZSBhIGZldyAmcXVvdDt0cmFu c3BvcnQmcXVvdDsgcHJvdG9jb2xzLCBhbmQgd2hpbGUgZWFjaCBvZiB0aGVtIGhhcyBoYWQgZGlm ZmVyZW50IHJlcXVpcmVtZW50cyBhbmQgYW1iaXRpb25zLCBJJ2QgbGlrZSB0byBvYnNlcnZlIHRo YXQgc3VjY2Vzc2Z1bCBvbmVzIG9mdGVuIGluY2x1ZGUgYW4gYWJpbGl0eSBmb3IgbmV0d29yayBv cGVyYXRvcnMgYW5kIGluZGVwZW5kZW50IHJlc2VhcmNoZXJzDQogdG8gYm90aCBnYXRoZXIgcGVy LWZsb3cgdHJhZmZpYyBtZWFzdXJlbWVudHMgYW5kIHRvIHVuZGVyc3RhbmQgcGF0aG9sb2dpZXMg b2YgaG93IHRyYWZmaWMgZmxvd3Mgc2hhcmUgY2FwYWNpdHkgYW5kIHVuZGVyc3RhbmQgd2hlcmUg cHJvYmxlbXMgZXhpc3Qgd2l0aGluIG5ldHdvcmtzLiBEb2luZyB0aGlzIHdpdGhpbiB0aGUgbmV0 d29yayByZWxpZXMgb24gdmlzaWJpbGl0eSBvZiBhdCBsZWFzdCBmaWVsZHMgd2l0aCB2aXNpYmls aXR5IG9mIGJhc2ljDQogZmxvdyBpbmZvcm1hdGlvbiBpbiB0aGUgcGF5bG9hZC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJdCdzIE9LIGZybyBtZSB0b2hhdmUgcnVsZXMgYWJvdXQgd2hldGhlciBwYWNr ZXQgbnVtYmVycyBoYXZlIHRvIG1vbm90b21pY2FsbHkgaW5jcmVhc2UgdG8gYmUgdXNlZnVsIGF0 IGEgcmVjZWl2ZXIsIHdoZXRoZXIgcmVjZWl2ZXJzIGNhbiB1c2VmdWxseSB1c2UgcmUtcmVzZXF1 ZW5jZWQgcGFja2V0cywgb3IgZGF0YSB3aXRoIGdhcHMsIGV0Yy4gRXZlbiB3aXRoIHRoZXNlIGNv bnN0cmFpbnRzLCBhIHNldCBvZiB2aXNpYmxlIGZpZWxkcyBjb3VsZA0KIHN0aWxsIG9wZW4tdXAg ZGF0YSBvbiB3aGV0aGVyIG15IGN1cnJlbnQgbmV0d29yayBsaW5rIGlzIHNlZWluZyBtb3JlICZx dW90O2dhcHMmcXVvdDssICZxdW90O3Jlc2VxdWVuY2luZyZxdW90OywgJnF1b3Q7d2hhdGV2ZXIm cXVvdDsgY29tcGFyZWQgdG8gYSBtZWFzdXJlbWVudCBhdCBhbm90aGVyIHRpbWUgb2YgZGF5LCBv ciBhbm90aGVyIHR5cGUgb2YgbmV0d29yayBsaW5rIC0gYWxsIG9mIHdoaWNoIGNhbiBiZSBoZWxw ZnVsIGluIHVuZGVyc3RhbmRpbmcgaG93IHRvIG9wZXJhdGUgbXkgbmV0d29yaywNCiBhbmQgd2hl dGhlciB0aGlzIHRyYWZmaWMgaXMgY28tZXhpc3Rpbmcgd2l0aCBvdGhlciB0cmFuc3BvcnQgc2Vy dmljZXMuIEFzIHdlIGxvb2sgYWhlYWQgdG8gbmV0d29ya3Mgd2l0aCBncmVhdGVyIHZhcmlhYmls aXR5ICg1Rz8pLCBtb3JlIHJlb3JkZXJpbmcsIG9yIHdpZGVyIG1peGVzIG9mIHRyYWZmaWMgYW5k IGZvcndhcmRpbmcgcnVsZXMsIHRoaXMgYmVjb21lcyBtb3JlIGltcG9ydGFudCwgbm90IGxlc3Mu PGJyPg0KJmd0Ozxicj4NCiZndDsgR29ycnk8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg T24gMzEvMDEvMjAxNyAwMDozNSwgTWFydGluIFRob21zb24gd3JvdGU6PGJyPg0KJmd0OyBPbiAz MSBKYW51YXJ5IDIwMTcgYXQgMDQ6MDgsIE1pcmphIEvDvGhsZXdpbmQ8YnI+DQomZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCI+bWlyamEua3Vl aGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT4mZ3Q7Jm5ic3A7IHdyb3RlOjxicj4NCiZndDsgLSBw YWNrZXQgbnVtYmVyIChjYW4gYmUgdXNlZCBmb3IgbG9zcyBkZXRlY3Rpb24gb2YgbG9zc2VzIHRo YXQgb2NjdXJyZWQgYmVmb3JlIHRoZSBvYnNlcnZhdGlvbiBwb2ludCBpZiBpbmNyZWFzZWQgbGlu ZWFybHkgd2l0aG91dCBnYXBzKSwgYW5kPGJyPg0KJmd0OyBPbiB0aGlzIHBvaW50LCBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgc2tpcCBwYWNrZXQgbnVtYmVyczxicj4NCiZndDsgcGVyaW9kaWNh bGx5LiZuYnNwOyBUaGF0IGxvb2tzIGxpa2UgbG9zcyB0byB0aGUgb3RoZXIgc2lkZSAob3IgdGhl IHBhdGgpLDxicj4NCiZndDsgYnV0IGV2ZW4gc3B1cmlvdXMgbG9zc2VzIGRvbid0IGhhdmUgYSBi aXQgaW1wYWN0IG9uIHRoaW5ncyBsaWtlPGJyPg0KJmd0OyBjb25nZXN0aW9uIGNvbnRyb2wgaWYg dGhleSBhcmUgcmFyZSBlbm91Z2guPGJyPg0KJmd0Ozxicj4NCiZndDsgT25lIHRoaW5nIHRoYXQg d2UndmUgZGlzY3Vzc2VkIGlzIHRoZSB1c2Ugb2YgZ2FwcyB0byB2ZXJpZnkgcGFja2V0PGJyPg0K Jmd0OyByZWNlaXB0IGFmdGVyIGEgY29ubmVjdGlvbiBtaWdyYXRpb24uJm5ic3A7IEFuIGVuZHBv aW50IHRoYXQgZGV0ZWN0cyBhIG1vdmU8YnI+DQomZ3Q7IGNhbiBzdGFydCBza2lwcGluZyBtb3Jl IGFnZ3Jlc3NpdmVseSB0byBwcm90ZWN0IGFnYWluc3Qgb3B0aW1pc3RpYyBhY2s8YnI+DQomZ3Q7 IGF0dGFja3Mgb24gdGhhdCBuZXcgcGF0aC4mbmJzcDsgSSBndWVzcyB0aGF0IHlvdSBjb3VsZCBh cmd1ZSB0aGF0IGVjaG9pbmcgYTxicj4NCiZndDsgcGFja2V0IG51bWJlciBhY2hpZXZlcyB0aGUg c2FtZSBlZmZlY3QgbW9yZSBlZmZpY2llbnRseSwgYnV0IHdlIHdvdWxkPGJyPg0KJmd0OyBuZWVk IHRvIGFzc2VzcyB0aGF0IGluIHRoZSBjb250ZXh0IG9mIHRoZSBieXRlcyBpdCB3b3VsZCBleHBl bmQ8YnI+DQomZ3Q7IG92ZXJhbGwuPGJyPg0KJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CY4PR03MB2533AC0E1A2E46169AB89443B64A0CY4PR03MB2533namp_-- From nobody Tue Jan 31 12:02: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 95244129A10 for ; Tue, 31 Jan 2017 12:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 ndyhKN1uS97K for ; Tue, 31 Jan 2017 12:02:36 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71809129A0A for ; Tue, 31 Jan 2017 12:02:35 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cYedN-0006q4-66 for quic@ietf.org; Tue, 31 Jan 2017 21:02:34 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cYedJ-0007tU-GL for quic@ietf.org; Tue, 31 Jan 2017 15:02:32 -0500 Received: (qmail 9916 invoked from network); 31 Jan 2017 20:02:28 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 31 Jan 2017 20:02:28 -0000 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Jana Iyengar References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> From: Christian Huitema Message-ID: Date: Tue, 31 Jan 2017 10:02:26 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Ossification X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrDLY+wVv6bjE9yMQjKh9iTRcOb18WfxGyg6Om6u4YYmxd0R1gqg1pXVZmp vS/pCaU5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQxQRCdMNhge1Unb77YyuZq5e8H7tK23DaIk8skFogDAERBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYIrCC8Nep3neMdH/yHViF2AeYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8tEzDd JFEeZx0L8qYzBLK5yNBqLkXGaznuCfaQ1w/JpOE= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:02:37 -0000 On 1/31/2017 9:24 AM, Mirja Kühlewind wrote: ... > That’s my point. Knowing that the position of the connection ID will > ossify, we should maybe consider to actively decide that we want to > support that and design the protocol respectively. Maybe we should start with an analysis of what the connection ID is used for, and determine which of these uses requires bytes in the header, versus for example an option in a connect message. And maybe how many bytes. So far the candidates are: 1) Demultiplexing at receiver. Arguably, this can be also be done by just looking at port numbers. 2) Reconnecting after a NAT mapping change. Without a connection ID, this would have to be treated like any other mobility event. 3) Reconnecting after a mobility event. The connection ID provides a simple mechanism. Without connection ID, we would have to do an explicit connection resume, similar to TLS resume. 4) Load balancing over several paths, as in TCP multipath. Connection ID enables a simple solution, perhaps too simple. TCP multipath manages separate sequence numbers and congestion controls for each path, and to do that we would need different connection ID for each path. For mobility and multipath, having the connection ID in all packets has a substantial privacy downside, so arguably we will need to develop "something like TLS resume" in any case. So maybe we need to think really hard about these issues! -- Christian Huitema From nobody Tue Jan 31 12:06: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 C9A19129A0D for ; Tue, 31 Jan 2017 12:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg-1kWqnEViC for ; Tue, 31 Jan 2017 12:06:08 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A51129537 for ; Tue, 31 Jan 2017 12:06:06 -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=7xVoXDdaRfy16z9M8J6qq7+wNx50zY/c/h7qCMQSXeE=; b=CkKCZfLLsjor8B1jr8h4VFsZKX4VxtUEvsB9y6yA3Nt5K5DPY2bnw2vRs5pMBRm4QRwM99F6iHMB4yrvYidoAzeDYgq50qHe9qWYrmpixFrKg5L382j96lnKHdMUg0Y4axcpgQLz/Fxch+0nSslPei3lNkbd6Hzkf1ofuPcCS5U= Received: from CY4PR03MB2533.namprd03.prod.outlook.com (10.168.165.21) by CY4PR03MB2534.namprd03.prod.outlook.com (10.168.165.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 31 Jan 2017 20:06:04 +0000 Received: from CY4PR03MB2533.namprd03.prod.outlook.com ([10.168.165.21]) by CY4PR03MB2533.namprd03.prod.outlook.com ([10.168.165.21]) with mapi id 15.01.0860.026; Tue, 31 Jan 2017 20:06:04 +0000 From: Praveen Balasubramanian To: Praveen Balasubramanian , Jana Iyengar , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Ossification Thread-Topic: Ossification Thread-Index: AQHSext/oeEofLpKwEudNQ8G4u5lp6FRvaqAgACRa4CAAKHEAIAACDiAgAADsICAAAJw8IAABCow Date: Tue, 31 Jan 2017 20:06:04 +0000 Message-ID: References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:a::616] x-ms-office365-filtering-correlation-id: 463a0dd2-ff8a-4b94-a4fe-08d44a14963b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR03MB2534; x-microsoft-exchange-diagnostics: 1; CY4PR03MB2534; 7:MKByk/EOi02URW4ZIEeCaB9EP+8yTr0z8iAp5pmgW4sW5zeT+v5tZqW7+cZnJ6KyY644Eolz6xA/5rtEuBQ4n2WNQI8qWD01YJi5naYKf7ta79+Y0udtMWQdNRO+bpgi1mjZvjNaUX7ISYwZ44HjNPgUzwKHg+K0isVt0cn7t/yTC5uyPr+q9wMg9/J/hsv6jLqxbIrUN8ByStORE4EwauDoJiwGyg0cQoqisPH3hXW4b4OHKthQi8guXI7nmRBcQuKgx5uwGFzcjcvvrYZqtijAVxIYonlkkWJOkA96acW5Z3X30KCtF54Go/jD/7G3qGY/Ib3jnwArymEh5SYoW3Mf/EPaF/m3wIdSF0m68fcxuS9+IBcw/cDCejOzV0Zt6TY2r99saj2+iJoIzClr9c3+s2NhsFGHogeYKR013qRF6exwj6c7Hh6RF0c4I6K5/l3fRoiLMcJXAulVJlYGtHTad7KOKNbA4xsghAVQr7mM3q8aedvVrynBdJgGMCSrvtHIAsVZQPeGdVlumdLcI7fz6YEpo1eCRdVyBmnsjxg= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(192374486261705)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(6047074); SRVR:CY4PR03MB2534; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2534; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(189002)(377454003)(199003)(24454002)(2900100001)(74316002)(4326007)(54356999)(86612001)(3660700001)(2561002)(9686003)(189998001)(76176999)(122556002)(102836003)(5001770100001)(229853002)(39060400001)(236005)(10090500001)(7736002)(2906002)(6116002)(1511001)(53936002)(790700001)(6506006)(38730400001)(77096006)(50986999)(6436002)(97736004)(221733001)(99286003)(3280700002)(7116003)(93886004)(8990500004)(105586002)(106116001)(6306002)(19609705001)(54896002)(2421001)(55016002)(101416001)(92566002)(81156014)(8936002)(86362001)(81166006)(33656002)(5660300001)(25786008)(68736007)(3480700004)(8676002)(7696004)(10290500002)(106356001)(5005710100001)(54906002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2534; H:CY4PR03MB2533.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR03MB25333BC3314F3776D4170B4FB64A0CY4PR03MB2533namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 20:06:04.4693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2534 Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:06:11 -0000 --_000_CY4PR03MB25333BC3314F3776D4170B4FB64A0CY4PR03MB2533namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIGFkZCB0aGF0IHRvZGF5IFJTUyBhbmQgRUNNUCBmb3IgVURQIGxpa2Vs eSBkb27igJl0IGRvIGZsb3cgbGV2ZWwgbG9hZCBiYWxhbmNpbmcgYW5kIHN0aWNrIHRvIHVzaW5n IHRoZSB0d28tdHVwbGUgKHNyYyBJUCwgZGVzdCBJUCkgYmVjYXVzZSBVRFAgdHJhZmZpYyBjYW4g YmUgZnJhZ21lbnRlZCBzbyBwYWNrZXRzIG9mIHRoZSBzYW1lIGZsb3cgY291bGQgZ2V0IHJlb3Jk ZXJlZC4gVGhlIHF1ZXN0aW9uIGlzIHdvdWxkIHdlIHdhbnQgdGhpcyB0byBiZSBiZXR0ZXIgZm9y IFFVSUMgZ2l2ZW4gdGhhdCBpdHMgbGlrZWx5IHRvIGVtdWxhdGUgVENQIGFuZCBub3QgZnJhZ21l bnQgcGFja2V0cy4gSSBzZWUgdGhhdCBDaHJpc3RpYW4gaGFzIGJyb3VnaHQgdXAgcHJpdmFjeSBj b25jZXJucyBvdmVyIGNvbm5lY3Rpb24gSUQgYmVpbmcgaW4gdGhlIGNsZWFyIHdoaWNoIGlzIGEg dmFsaWQgY29uY2VybiBzbyB0aGVyZeKAmXMgYWxzbyBhIHNlY3VyaXR5IHZzLiBwZXJmb3JtYW5j ZSB0cmFkZW9mZi4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDMxLCAyMDE3IDExOjU5IEFNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47 IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+DQpDYzog R29ycnkgKGVyZykgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPjsgSUVURiBRVUlDIFdHIDxxdWljQGll dGYub3JnPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NClN1Ympl Y3Q6IFJFOiBPc3NpZmljYXRpb24NCg0KDQpZZXMgYXQgbGVhc3QgdGhlIGNvbm5lY3Rpb24gSUQg bXVzdCBiZSBpbiB0aGUgY2xlYXIgZm9yIGxvYWQgYmFsYW5jaW5nIHB1cnBvc2VzIC0gYm90aCBp biB0aGUgbmV0d29yayBmb3IgRUNNUCBhbmQgaW4gdGhlIGVuZCBob3N0IGZvciBzcHJlYWRpbmcg dHJhZmZpYyBhbW9uZ3N0IGNvcmVzLiBFc3NlbnRpYWxseSBJIGRvbuKAmXQgdGhpbmsgd2UgY2Fu IGFzc3VtZSB0aGF0IGFsbCBtaWRkbGVib3hlcyB3aWxsIGJlIHN0YXRlZnVsIG9yIHRoYXQgdGhl cmUgd2lsbCBiZSBubyBuZWVkIGZvciBzdGF0ZWxlc3Mgb2ZmbG9hZHMgdG8gdGhlIE5JQ3MuIEFu ZCBmb3Igc3VjaCB1c2UgY2FzZXMgYmVpbmcgYWJsZSB0byBkaXN0aW5ndWlzaCBRVUlDIHRyYWZm aWMgaXMgdmVyeSB1c2VmdWwgdG8gYXZvaWQgZm9yIGV4YW1wbGUgc3ByZWFkaW5nIG90aGVyIFVE UCB0cmFmZmljIGNhdXNpbmcgcGFja2V0IHJlb3JkZXJpbmcgYW5kIHJlYXNzZW1ibHkgZXRjLiBT byBJIHRoaW5rIGEgbWFnaWMgbnVtYmVyIGlzIHVzZWZ1bCBub3Qgb25seSB0byBkaXN0aW5ndWlz aCBRVUlDIGFuZCBRVUlDIHZlcnNpb25zIGJ1dCBhbHNvIHRvIGRpc3Rpbmd1aXNoIG90aGVyIFVE UCB0cmFmZmljLiBCdXQgc3VjaCBhIGdlbmVyaWMgbWVjaGFuaXNtIGZvciBVRFAgaXMgcHJlc3Vt YWJseSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHdvcmtpbmcgZ3JvdXA/DQoNCg0KDQpUaGFu a3MNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEphbmEgSXllbmdhcg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAzMSwgMjAxNyAxMTozOCBB TQ0KVG86IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8 bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+Pg0KQ2M6IEdvcnJ5IChlcmcp IDxnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PjsgSUVU RiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hcnRpbiBU aG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogT3NzaWZpY2F0aW9uDQoNCg0KDQpPbiBUdWUsIEphbiAz MSwgMjAxNyBhdCAxMToyNCBBTSwgTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0 aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4+IHdy b3RlOg0KSGkgSmFuYSwNCg0KYSBmZXcgY29tbWVudHMgYmVsb3cuDQoNCj4gQW0gMzEuMDEuMjAx NyB1bSAxOTo1NSBzY2hyaWViIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpy aUBnb29nbGUuY29tPj46DQo+DQo+IEknbSBsb2F0aGUgdG8gaW5jcmVhc2UgdGhlIFFVSUMgcGFj a2V0IGhlYWRlciBzaXplIHRvIGF2b2lkIGluY3JlYXNpbmdseSBhZGRpdGlvbmFsIG92ZXJoZWFk LiBJIGFncmVlIHRoYXQgKDEpIHNlZW1zIGZ1bmRhbWVudGFsbHkgaGFyZCB0byBkbyB3aXRob3V0 IHN1YnN0YW50aWFsIGNvbXB1dGF0aW9uYWwgY29zdCBhbmQgb3RoZXIgb3ZlcmhlYWQsIHNvIEkn ZCBiZSBmaW5lIHdpdGggZXhwb3Npbmcgc29tZSB0aGluZ3MuIEkgdGhpbmsgdGhpcyBpcyBleHBl Y3RlZCB0byBiZSBkaXNjdXNzZWQgaW4gQ2hpY2FnbyBhbnl3YXlzLCBGV0lXLg0KPg0KPiBUaGF0 IHNhaWQsIG15IGV4cGVjdGF0aW9uIGlzIHRoYXQgdGhlcmUgYXJlIHRocmVlIHR5cGVzIG9mIG1p ZGRsZWJveGVzIHRoYXQgd2Ugd2FudCB0byBhZGRyZXNzOg0KPiAoaSkgVGhvc2UgdGhhdCB3YW50 IHRvIHNlcGFyYXRlIFFVSUMgY29ubmVjdGlvbnMgZnJvbSB1bndhcnJhbnRlZCB0cmFmZmljOw0K PiAoaWkpIFRob3NlIHRoYXQgd2FudCB0byB0cmFjayBRVUlDIGNvbm5lY3Rpb24gc3RhdGU7IGFu ZA0KPiAoaWlpKSBUaG9zZSB0aGF0IHdhbnQgdG8gZmlyZXdhbGwgY2VydGFpbiBzZXJ2aWNlcyAo ZWcuLCBXZWJSVEMpLiBNaWRkbGVib3hlcyBhcmUgaW50ZXJlc3RlZCBpbiBibG9ja2luZyBzZXJ2 aWNlcywgbm90IHRoZSB0cmFuc3BvcnQuDQo+DQo+IChpaWkpIGlzIGJhc2ljYWxseSBzb2x2ZWQg dXNpbmcgdGhlIHNhbWUgc2lnbmFscyB0aGF0IG1pZGRsZWJveGVzIHVzZSB0b2RheTogc2VydmVy IHBvcnQgbnVtYmVyLiBCbG9ja2luZyBVRFAgdG8gcG9ydCA0NDMgZWZmZWN0aXZlbHkgYmxvY2tz IHVzZSBvZiBRVUlDIGZvciBIVFRQUy4NCj4NCj4gRm9yIChpKSBhbmQgKGlpKSwgaWYgbWlkZGxl Ym94ZXMgYXJlIGJlaW5nIG1vZGlmaWVkIHRvIGRldGVjdCBRVUlDLCBJIGRvbid0IHRoaW5rIHRo ZXknZCBoYXZlIHRyb3VibGUgZ29pbmcgdGhyb3VnaCB0aGUgc3RhdGUgbWFjaGluZSBhbmQgcmVt ZW1iZXJpbmcgd2hlcmUgdGhlIFFVSUMgY29ubmVjdGlvbiBJRCBmYWxscy4gSSBhcHByZWNpYXRl IHlvdXIgY29uY2VybiBhYm91dCBvc3NpZmljYXRpb24gb2Ygc3BlY2lmaWMgdmVyc2lvbnMsIGJ1 dCBpZiB0aGVyZSBhcmUgb3NzaWZpZWQgbWlkZGxlYm94ZXMgdGhhdCBuZWVkIHRvIHRyYWNrIGNv bm5lY3Rpb24gc3RhdGUgKHR5cGUgKGlpaSkgYWJvdmUpLCB0aGVuIHdlJ3JlIHN0dWNrIHdpdGgg dGhlIHBvc2l0aW9uIG9mIHRoZSBjb25uZWN0aW9uIElEIGFueXdheXMuDQoNClRoYXTigJlzIG15 IHBvaW50LiBLbm93aW5nIHRoYXQgdGhlIHBvc2l0aW9uIG9mIHRoZSBjb25uZWN0aW9uIElEIHdp bGwgb3NzaWZ5LCB3ZSBzaG91bGQgbWF5YmUgY29uc2lkZXIgdG8gYWN0aXZlbHkgZGVjaWRlIHRo YXQgd2Ugd2FudCB0byBzdXBwb3J0IHRoYXQgYW5kIGRlc2lnbiB0aGUgcHJvdG9jb2wgcmVzcGVj dGl2ZWx5Lg0KDQpJIGFncmVlLCBhbmQgSSB0aGluayB0aGlzIHNob3VsZCBiZSBkaXNjdXNzZWQu DQoNCj4NCj4gU3BlY2lmeWluZyB0aGUgdmVyc2lvbiBvciBzZW5kaW5nIGEgbWFnaWMgbnVtYmVy IGluIGVhY2ggcGFja2V0IGhhcyBxdWFudGlmaWFibGUgb3ZlcmhlYWQgY29zdCBidXQgdGhlIGJl bmVmaXRzIGFyZSB1bmtub3duLCBhbmQgSSdkIGJlIGluY2xpbmVkIGFnYWluc3QgdGhlbS4gRm9y IGluLW5ldHdvcmsgbWVhc3VyZW1lbnRzLCBhcyB3ZSd2ZSBkaXNjdXNzZWQgcHJldmlvdXNseSwg dGhlcmUgbWF5IGJlIHZhbHVlIGluIHNlbmRpbmcgdGhlICJsYXJnZXN0IG9ic2VydmVkIiBpbiB0 aGF0IGhlYWRlci4NCg0KV2UgYWxyZWFkeSBhZ3JlZWQgdGhhdCBoYXZpbmcgc29tZSBraW5kIG9m IGEgbWFnaWMgbnVtYmVyIGluIHRoZSB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tldHMgbWFrZXMg c2Vuc2UgdG8gYXZvaWQgY29uZmxpY3RzIHdpdGggb3RoZXIgVURQIHRyYWZmaWMuIElmIHlvdSBo YXZlIHNlZW4gdmVyc2lvbiBuZWdvdGlhdGlvbiwgeW91IGNhbiB1c2UgdGhlIGNvbm5lY3Rpb24g SUQgaW4gc3Vic2VxdWVudCBwYWNrZXRzIHRvIGFzc2lnbiBpdCB0byBhIGtub3duIGZsb3cgYW5k IGRpc3Rpbmd1aXNoIGl0IGZyb20gb3RoZXIgVURQLWJhc2VkIChjcm9zcykgdHJhZmZpYy4gSG93 ZXZlciwgaWYgeW91IGhhdmUgbm90IHNlZW4gdGhlIGhhbmRzaGFrZSwgdGhlcmUgaXMgbm8gd2F5 IHRvIGRpc3Rpbmd1aXNoIFVEUC1iYXNlZCBxdWljIHRyYWZmaWMuIFRoaXMgbWFrZXMgdGhlIHF1 aWMgaGFuZHNoYWtlIGEgc3BlY2lhbCBzaWduYWwgZm9yIHRoZSBuZXR3b3JrIHdoaWNoIEkgd291 bGQgcmF0aGVyIGxpa2UgdG8gYXZvaWQgYmVjYXVzZSBpdOKAmXMgbm90LiBZZXMsIHB1dHRpbmcg YSBtYWdpYyBudW1iZXIgaW4gYWxsIHBhY2tldHMgaXMgb3ZlcmhlYWQuIEJ1dCB0aGlzIGlzIHRo ZSB0cmFkZS1vZmYgSeKAmWQgbGlrZSB0byBkaXNjdXNzLg0KDQpJdCBpcyBhIHNwZWNpYWwgc2ln bmFsIC0tIGl0IGlzIHRoZSBiZWdpbm5pbmcgb2YgYSBRVUlDIGNvbm5lY3Rpb24uIEknbSBub3Qg c3VyZSB3aHkgeW91IHdvdWxkIGF2b2lkIHRoYXQuDQoNCklmIHlvdSdyZSBsb29raW5nIGZvciBh IG1hZ2ljIHNpZ25hbCBpbiBldmVyeSBwYWNrZXQsIEkgZG9uJ3QgdGhpbmsgaXQncyBnb2luZyB0 byBiZSBlZmZlY3RpdmUgaW4gdGhlIGxvbmcgdGVybS4gSXQncyBzaW1wbGUgZW5vdWdoIGZvciBm b2xrcyBnZW5lcmF0aW5nIGJvZ3VzIHRyYWZmaWMgdG8gc2VuZCBpdCB3aXRoIHRoZSBtYWdpYyBz aWduYWwuIElmIHlvdSdyZSB0cnlpbmcgdG8gdGh3YXJ0IHJlZGlyZWN0ZWQgdHJhZmZpYywgdGhl biB5b3UgbG9vayBmb3IgYSBoYW5kc2hha2Ugc2VxdWVuY2UsIHdoaWNoIGdpdmVzIHlvdSBhIHBp dm90IHRvIGhhbmcgdGhlIHJlc3Qgb2YgdGhlIGNvbm5lY3Rpb24gZnJvbS4NCg0KDQoNCk1pcmph DQoNCg0KPg0KPiBPbiBUdWUsIEphbiAzMSwgMjAxNyBhdCAxOjE2IEFNLCBHb3JyeSBGYWlyaHVy c3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+IHdy b3RlOg0KPiBJIHNlZSByZWFsIG1lcml0IGluIG1vdmluZyBiZXlvbmQgKDEpIGZvciBhbm90aGVy IHJlYXNvbiBpZiB0aGlzIGV4cG9zZXMgYXQgbGVhc3QgY29ubmVjdGlvbiBJRCwgcGFja2V0IG51 bWJlciwgcGFja2V0IG51bWJlciBlY2hvIChhc3VtaW5nIG9uZSBjYW4gYWxzbyBkZXJpdmUgKGJl Z2luL2VuZCBvZiBmbG93LCBldGMgZm9yIGEgdHJhZmZpYyBmbG93Lg0KPg0KPiBPdmVyIHRoZSB5 ZWFycyBJJ3ZlIHNlZW4gdGhlIElFVEYgcHJvZHVjZSBxdWl0ZSBhIGZldyAidHJhbnNwb3J0IiBw cm90b2NvbHMsIGFuZCB3aGlsZSBlYWNoIG9mIHRoZW0gaGFzIGhhZCBkaWZmZXJlbnQgcmVxdWly ZW1lbnRzIGFuZCBhbWJpdGlvbnMsIEknZCBsaWtlIHRvIG9ic2VydmUgdGhhdCBzdWNjZXNzZnVs IG9uZXMgb2Z0ZW4gaW5jbHVkZSBhbiBhYmlsaXR5IGZvciBuZXR3b3JrIG9wZXJhdG9ycyBhbmQg aW5kZXBlbmRlbnQgcmVzZWFyY2hlcnMgdG8gYm90aCBnYXRoZXIgcGVyLWZsb3cgdHJhZmZpYyBt ZWFzdXJlbWVudHMgYW5kIHRvIHVuZGVyc3RhbmQgcGF0aG9sb2dpZXMgb2YgaG93IHRyYWZmaWMg Zmxvd3Mgc2hhcmUgY2FwYWNpdHkgYW5kIHVuZGVyc3RhbmQgd2hlcmUgcHJvYmxlbXMgZXhpc3Qg d2l0aGluIG5ldHdvcmtzLiBEb2luZyB0aGlzIHdpdGhpbiB0aGUgbmV0d29yayByZWxpZXMgb24g dmlzaWJpbGl0eSBvZiBhdCBsZWFzdCBmaWVsZHMgd2l0aCB2aXNpYmlsaXR5IG9mIGJhc2ljIGZs b3cgaW5mb3JtYXRpb24gaW4gdGhlIHBheWxvYWQuDQo+DQo+IEl0J3MgT0sgZnJvIG1lIHRvaGF2 ZSBydWxlcyBhYm91dCB3aGV0aGVyIHBhY2tldCBudW1iZXJzIGhhdmUgdG8gbW9ub3RvbWljYWxs eSBpbmNyZWFzZSB0byBiZSB1c2VmdWwgYXQgYSByZWNlaXZlciwgd2hldGhlciByZWNlaXZlcnMg Y2FuIHVzZWZ1bGx5IHVzZSByZS1yZXNlcXVlbmNlZCBwYWNrZXRzLCBvciBkYXRhIHdpdGggZ2Fw cywgZXRjLiBFdmVuIHdpdGggdGhlc2UgY29uc3RyYWludHMsIGEgc2V0IG9mIHZpc2libGUgZmll bGRzIGNvdWxkIHN0aWxsIG9wZW4tdXAgZGF0YSBvbiB3aGV0aGVyIG15IGN1cnJlbnQgbmV0d29y ayBsaW5rIGlzIHNlZWluZyBtb3JlICJnYXBzIiwgInJlc2VxdWVuY2luZyIsICJ3aGF0ZXZlciIg Y29tcGFyZWQgdG8gYSBtZWFzdXJlbWVudCBhdCBhbm90aGVyIHRpbWUgb2YgZGF5LCBvciBhbm90 aGVyIHR5cGUgb2YgbmV0d29yayBsaW5rIC0gYWxsIG9mIHdoaWNoIGNhbiBiZSBoZWxwZnVsIGlu IHVuZGVyc3RhbmRpbmcgaG93IHRvIG9wZXJhdGUgbXkgbmV0d29yaywgYW5kIHdoZXRoZXIgdGhp cyB0cmFmZmljIGlzIGNvLWV4aXN0aW5nIHdpdGggb3RoZXIgdHJhbnNwb3J0IHNlcnZpY2VzLiBB cyB3ZSBsb29rIGFoZWFkIHRvIG5ldHdvcmtzIHdpdGggZ3JlYXRlciB2YXJpYWJpbGl0eSAoNUc/ KSwgbW9yZSByZW9yZGVyaW5nLCBvciB3aWRlciBtaXhlcyBvZiB0cmFmZmljIGFuZCBmb3J3YXJk aW5nIHJ1bGVzLCB0aGlzIGJlY29tZXMgbW9yZSBpbXBvcnRhbnQsIG5vdCBsZXNzLg0KPg0KPiBH b3JyeQ0KPg0KPg0KPiBPbiAzMS8wMS8yMDE3IDAwOjM1LCBNYXJ0aW4gVGhvbXNvbiB3cm90ZToN Cj4gT24gMzEgSmFudWFyeSAyMDE3IGF0IDA0OjA4LCBNaXJqYSBLw7xobGV3aW5kDQo+IDxtaXJq YS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5l ZS5ldGh6LmNoPj4gIHdyb3RlOg0KPiAtIHBhY2tldCBudW1iZXIgKGNhbiBiZSB1c2VkIGZvciBs b3NzIGRldGVjdGlvbiBvZiBsb3NzZXMgdGhhdCBvY2N1cnJlZCBiZWZvcmUgdGhlIG9ic2VydmF0 aW9uIHBvaW50IGlmIGluY3JlYXNlZCBsaW5lYXJseSB3aXRob3V0IGdhcHMpLCBhbmQNCj4gT24g dGhpcyBwb2ludCwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHNraXAgcGFja2V0IG51bWJlcnMN Cj4gcGVyaW9kaWNhbGx5LiAgVGhhdCBsb29rcyBsaWtlIGxvc3MgdG8gdGhlIG90aGVyIHNpZGUg KG9yIHRoZSBwYXRoKSwNCj4gYnV0IGV2ZW4gc3B1cmlvdXMgbG9zc2VzIGRvbid0IGhhdmUgYSBi aXQgaW1wYWN0IG9uIHRoaW5ncyBsaWtlDQo+IGNvbmdlc3Rpb24gY29udHJvbCBpZiB0aGV5IGFy ZSByYXJlIGVub3VnaC4NCj4NCj4gT25lIHRoaW5nIHRoYXQgd2UndmUgZGlzY3Vzc2VkIGlzIHRo ZSB1c2Ugb2YgZ2FwcyB0byB2ZXJpZnkgcGFja2V0DQo+IHJlY2VpcHQgYWZ0ZXIgYSBjb25uZWN0 aW9uIG1pZ3JhdGlvbi4gIEFuIGVuZHBvaW50IHRoYXQgZGV0ZWN0cyBhIG1vdmUNCj4gY2FuIHN0 YXJ0IHNraXBwaW5nIG1vcmUgYWdncmVzc2l2ZWx5IHRvIHByb3RlY3QgYWdhaW5zdCBvcHRpbWlz dGljIGFjaw0KPiBhdHRhY2tzIG9uIHRoYXQgbmV3IHBhdGguICBJIGd1ZXNzIHRoYXQgeW91IGNv dWxkIGFyZ3VlIHRoYXQgZWNob2luZyBhDQo+IHBhY2tldCBudW1iZXIgYWNoaWV2ZXMgdGhlIHNh bWUgZWZmZWN0IG1vcmUgZWZmaWNpZW50bHksIGJ1dCB3ZSB3b3VsZA0KPiBuZWVkIHRvIGFzc2Vz cyB0aGF0IGluIHRoZSBjb250ZXh0IG9mIHRoZSBieXRlcyBpdCB3b3VsZCBleHBlbmQNCj4gb3Zl cmFsbC4NCj4NCj4NCg0K --_000_CY4PR03MB25333BC3314F3776D4170B4FB64A0CY4PR03MB2533namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5o b2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIGFkZCB0aGF0IHRv ZGF5IFJTUyBhbmQgRUNNUCBmb3IgVURQIGxpa2VseSBkb27igJl0IGRvIGZsb3cgbGV2ZWwgbG9h ZCBiYWxhbmNpbmcgYW5kIHN0aWNrIHRvIHVzaW5nIHRoZSB0d28tdHVwbGUgKHNyYyBJUCwgZGVz dCBJUCkgYmVjYXVzZSBVRFAgdHJhZmZpYyBjYW4gYmUgZnJhZ21lbnRlZCBzbyBwYWNrZXRzIG9m IHRoZSBzYW1lIGZsb3cgY291bGQgZ2V0IHJlb3JkZXJlZC4gVGhlDQogcXVlc3Rpb24gaXMgd291 bGQgd2Ugd2FudCB0aGlzIHRvIGJlIGJldHRlciBmb3IgUVVJQyBnaXZlbiB0aGF0IGl0cyBsaWtl bHkgdG8gZW11bGF0ZSBUQ1AgYW5kIG5vdCBmcmFnbWVudCBwYWNrZXRzLiBJIHNlZSB0aGF0IENo cmlzdGlhbiBoYXMgYnJvdWdodCB1cCBwcml2YWN5IGNvbmNlcm5zIG92ZXIgY29ubmVjdGlvbiBJ RCBiZWluZyBpbiB0aGUgY2xlYXIgd2hpY2ggaXMgYSB2YWxpZCBjb25jZXJuIHNvIHRoZXJl4oCZ cyBhbHNvIGEgc2VjdXJpdHkNCiB2cy4gcGVyZm9ybWFuY2UgdHJhZGVvZmYuIDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0K PC9iPlByYXZlZW4gQmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEph bnVhcnkgMzEsIDIwMTcgMTE6NTkgQU08YnI+DQo8Yj5Ubzo8L2I+IEphbmEgSXllbmdhciAmbHQ7 anJpQGdvb2dsZS5jb20mZ3Q7OyBNaXJqYSBLw7xobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoJmd0Ozxicj4NCjxiPkNjOjwvYj4gR29ycnkgKGVyZykgJmx0O2dvcnJ5 QGVyZy5hYmRuLmFjLnVrJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozsg TWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IE9zc2lmaWNhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+WWVzIGF0IGxlYXN0IHRoZSBjb25uZWN0aW9uIElEIG11c3QgYmUgaW4g dGhlIGNsZWFyIGZvciBsb2FkIGJhbGFuY2luZyBwdXJwb3NlcyAtIGJvdGggaW4gdGhlIG5ldHdv cmsgZm9yIEVDTVAgYW5kIGluIHRoZSBlbmQgaG9zdCBmb3Igc3ByZWFkaW5nIHRyYWZmaWMgYW1v bmdzdCBjb3Jlcy4gRXNzZW50aWFsbHkgSSBkb27igJl0IHRoaW5rIHdlIGNhbiBhc3N1bWUgdGhh dCBhbGwgbWlkZGxlYm94ZXMgd2lsbA0KIGJlIHN0YXRlZnVsIG9yIHRoYXQgdGhlcmUgd2lsbCBi ZSBubyBuZWVkIGZvciBzdGF0ZWxlc3Mgb2ZmbG9hZHMgdG8gdGhlIE5JQ3MuIEFuZCBmb3Igc3Vj aCB1c2UgY2FzZXMgYmVpbmcgYWJsZSB0byBkaXN0aW5ndWlzaCBRVUlDIHRyYWZmaWMgaXMgdmVy eSB1c2VmdWwgdG8gYXZvaWQgZm9yIGV4YW1wbGUgc3ByZWFkaW5nIG90aGVyIFVEUCB0cmFmZmlj IGNhdXNpbmcgcGFja2V0IHJlb3JkZXJpbmcgYW5kIHJlYXNzZW1ibHkgZXRjLiBTbyBJIHRoaW5r DQogYSBtYWdpYyBudW1iZXIgaXMgdXNlZnVsIG5vdCBvbmx5IHRvIGRpc3Rpbmd1aXNoIFFVSUMg YW5kIFFVSUMgdmVyc2lvbnMgYnV0IGFsc28gdG8gZGlzdGluZ3Vpc2ggb3RoZXIgVURQIHRyYWZm aWMuIEJ1dCBzdWNoIGEgZ2VuZXJpYyBtZWNoYW5pc20gZm9yIFVEUCBpcyBwcmVzdW1hYmx5IG91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgd29ya2luZyBncm91cD88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBR VUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFuYSBJeWVuZ2FyPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTcgMTE6MzggQU08YnI+DQo8 Yj5Ubzo8L2I+IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+IEdvcnJ5IChlcmcpICZsdDs8YSBocmVmPSJtYWlsdG86Z29y cnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDs7IElFVEYgUVVJ QyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+ Jmd0OzsgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBPc3NpZmljYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFuIDMx LCAyMDE3IGF0IDExOjI0IEFNLCBNaXJqYSBLw7xobGV3aW5kICZsdDs8YSBocmVmPSJtYWlsdG86 bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxhbmsiPm1pcmphLmt1 ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgSmFuYSw8YnI+DQo8YnI+DQphIGZldyBjb21tZW50cyBiZWxvdy48YnI+ DQo8YnI+DQomZ3Q7IEFtIDMxLjAxLjIwMTcgdW0gMTk6NTUgc2NocmllYiBKYW5hIEl5ZW5nYXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+anJpQGdvb2dsZS5jb208L2E+Jmd0 Ozo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gbG9hdGhlIHRvIGluY3JlYXNlIHRoZSBRVUlDIHBh Y2tldCBoZWFkZXIgc2l6ZSB0byBhdm9pZCBpbmNyZWFzaW5nbHkgYWRkaXRpb25hbCBvdmVyaGVh ZC4gSSBhZ3JlZSB0aGF0ICgxKSBzZWVtcyBmdW5kYW1lbnRhbGx5IGhhcmQgdG8gZG8gd2l0aG91 dCBzdWJzdGFudGlhbCBjb21wdXRhdGlvbmFsIGNvc3QgYW5kIG90aGVyIG92ZXJoZWFkLCBzbyBJ J2QgYmUgZmluZSB3aXRoIGV4cG9zaW5nIHNvbWUgdGhpbmdzLiBJIHRoaW5rIHRoaXMNCiBpcyBl eHBlY3RlZCB0byBiZSBkaXNjdXNzZWQgaW4gQ2hpY2FnbyBhbnl3YXlzLCBGV0lXLjxicj4NCiZn dDs8YnI+DQomZ3Q7IFRoYXQgc2FpZCwgbXkgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGVyZSBhcmUg dGhyZWUgdHlwZXMgb2YgbWlkZGxlYm94ZXMgdGhhdCB3ZSB3YW50IHRvIGFkZHJlc3M6PGJyPg0K Jmd0OyAoaSkgVGhvc2UgdGhhdCB3YW50IHRvIHNlcGFyYXRlIFFVSUMgY29ubmVjdGlvbnMgZnJv bSB1bndhcnJhbnRlZCB0cmFmZmljOzxicj4NCiZndDsgKGlpKSBUaG9zZSB0aGF0IHdhbnQgdG8g dHJhY2sgUVVJQyBjb25uZWN0aW9uIHN0YXRlOyBhbmQ8YnI+DQomZ3Q7IChpaWkpIFRob3NlIHRo YXQgd2FudCB0byBmaXJld2FsbCBjZXJ0YWluIHNlcnZpY2VzIChlZy4sIFdlYlJUQykuIE1pZGRs ZWJveGVzIGFyZSBpbnRlcmVzdGVkIGluIGJsb2NraW5nIHNlcnZpY2VzLCBub3QgdGhlIHRyYW5z cG9ydC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAoaWlpKSBpcyBiYXNpY2FsbHkgc29sdmVkIHVzaW5n IHRoZSBzYW1lIHNpZ25hbHMgdGhhdCBtaWRkbGVib3hlcyB1c2UgdG9kYXk6IHNlcnZlciBwb3J0 IG51bWJlci4gQmxvY2tpbmcgVURQIHRvIHBvcnQgNDQzIGVmZmVjdGl2ZWx5IGJsb2NrcyB1c2Ug b2YgUVVJQyBmb3IgSFRUUFMuPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIChpKSBhbmQgKGlpKSwg aWYgbWlkZGxlYm94ZXMgYXJlIGJlaW5nIG1vZGlmaWVkIHRvIGRldGVjdCBRVUlDLCBJIGRvbid0 IHRoaW5rIHRoZXknZCBoYXZlIHRyb3VibGUgZ29pbmcgdGhyb3VnaCB0aGUgc3RhdGUgbWFjaGlu ZSBhbmQgcmVtZW1iZXJpbmcgd2hlcmUgdGhlIFFVSUMgY29ubmVjdGlvbiBJRCBmYWxscy4gSSBh cHByZWNpYXRlIHlvdXIgY29uY2VybiBhYm91dCBvc3NpZmljYXRpb24gb2Ygc3BlY2lmaWMgdmVy c2lvbnMsIGJ1dA0KIGlmIHRoZXJlIGFyZSBvc3NpZmllZCBtaWRkbGVib3hlcyB0aGF0IG5lZWQg dG8gdHJhY2sgY29ubmVjdGlvbiBzdGF0ZSAodHlwZSAoaWlpKSBhYm92ZSksIHRoZW4gd2UncmUg c3R1Y2sgd2l0aCB0aGUgcG9zaXRpb24gb2YgdGhlIGNvbm5lY3Rpb24gSUQgYW55d2F5cy48YnI+ DQo8YnI+DQpUaGF04oCZcyBteSBwb2ludC4gS25vd2luZyB0aGF0IHRoZSBwb3NpdGlvbiBvZiB0 aGUgY29ubmVjdGlvbiBJRCB3aWxsIG9zc2lmeSwgd2Ugc2hvdWxkIG1heWJlIGNvbnNpZGVyIHRv IGFjdGl2ZWx5IGRlY2lkZSB0aGF0IHdlIHdhbnQgdG8gc3VwcG9ydCB0aGF0IGFuZCBkZXNpZ24g dGhlIHByb3RvY29sIHJlc3BlY3RpdmVseS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUsIGFuZCBJIHRoaW5rIHRoaXMg c2hvdWxkIGJlIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDs8YnI+DQomZ3Q7IFNwZWNpZnlpbmcgdGhlIHZlcnNpb24gb3Igc2VuZGluZyBhIG1h Z2ljIG51bWJlciBpbiBlYWNoIHBhY2tldCBoYXMgcXVhbnRpZmlhYmxlIG92ZXJoZWFkIGNvc3Qg YnV0IHRoZSBiZW5lZml0cyBhcmUgdW5rbm93biwgYW5kIEknZCBiZSBpbmNsaW5lZCBhZ2FpbnN0 IHRoZW0uIEZvciBpbi1uZXR3b3JrIG1lYXN1cmVtZW50cywgYXMgd2UndmUgZGlzY3Vzc2VkIHBy ZXZpb3VzbHksIHRoZXJlIG1heSBiZSB2YWx1ZSBpbiBzZW5kaW5nIHRoZSAmcXVvdDtsYXJnZXN0 DQogb2JzZXJ2ZWQmcXVvdDsgaW4gdGhhdCBoZWFkZXIuPGJyPg0KPGJyPg0KV2UgYWxyZWFkeSBh Z3JlZWQgdGhhdCBoYXZpbmcgc29tZSBraW5kIG9mIGEgbWFnaWMgbnVtYmVyIGluIHRoZSB2ZXJz aW9uIG5lZ290aWF0aW9uIHBhY2tldHMgbWFrZXMgc2Vuc2UgdG8gYXZvaWQgY29uZmxpY3RzIHdp dGggb3RoZXIgVURQIHRyYWZmaWMuIElmIHlvdSBoYXZlIHNlZW4gdmVyc2lvbiBuZWdvdGlhdGlv biwgeW91IGNhbiB1c2UgdGhlIGNvbm5lY3Rpb24gSUQgaW4gc3Vic2VxdWVudCBwYWNrZXRzIHRv IGFzc2lnbiBpdCB0byBhIGtub3duDQogZmxvdyBhbmQgZGlzdGluZ3Vpc2ggaXQgZnJvbSBvdGhl ciBVRFAtYmFzZWQgKGNyb3NzKSB0cmFmZmljLiBIb3dldmVyLCBpZiB5b3UgaGF2ZSBub3Qgc2Vl biB0aGUgaGFuZHNoYWtlLCB0aGVyZSBpcyBubyB3YXkgdG8gZGlzdGluZ3Vpc2ggVURQLWJhc2Vk IHF1aWMgdHJhZmZpYy4gVGhpcyBtYWtlcyB0aGUgcXVpYyBoYW5kc2hha2UgYSBzcGVjaWFsIHNp Z25hbCBmb3IgdGhlIG5ldHdvcmsgd2hpY2ggSSB3b3VsZCByYXRoZXIgbGlrZSB0byBhdm9pZA0K IGJlY2F1c2UgaXTigJlzIG5vdC4gWWVzLCBwdXR0aW5nIGEgbWFnaWMgbnVtYmVyIGluIGFsbCBw YWNrZXRzIGlzIG92ZXJoZWFkLiBCdXQgdGhpcyBpcyB0aGUgdHJhZGUtb2ZmIEnigJlkIGxpa2Ug dG8gZGlzY3Vzcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGlzIGEgc3BlY2lhbCBzaWduYWwgLS0gaXQgaXMgdGhlIGJlZ2lu bmluZyBvZiBhIFFVSUMgY29ubmVjdGlvbi4gSSdtIG5vdCBzdXJlIHdoeSB5b3Ugd291bGQgYXZv aWQgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SWYgeW91J3JlIGxvb2tpbmcgZm9yIGEgbWFnaWMgc2lnbmFsIGluIGV2ZXJ5IHBhY2tl dCwgSSBkb24ndCB0aGluayBpdCdzIGdvaW5nIHRvIGJlIGVmZmVjdGl2ZSBpbiB0aGUgbG9uZyB0 ZXJtLiBJdCdzIHNpbXBsZSBlbm91Z2ggZm9yIGZvbGtzIGdlbmVyYXRpbmcgYm9ndXMgdHJhZmZp YyB0byBzZW5kIGl0IHdpdGggdGhlIG1hZ2ljIHNpZ25hbC4gSWYgeW91J3JlIHRyeWluZyB0byB0 aHdhcnQgcmVkaXJlY3RlZA0KIHRyYWZmaWMsIHRoZW4geW91IGxvb2sgZm9yIGEgaGFuZHNoYWtl IHNlcXVlbmNlLCB3aGljaCBnaXZlcyB5b3UgYSBwaXZvdCB0byBoYW5nIHRoZSByZXN0IG9mIHRo ZSBjb25uZWN0aW9uIGZyb20uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpi Ij5NaXJqYTwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0K Jmd0Ozxicj4NCiZndDsgT24gVHVlLCBKYW4gMzEsIDIwMTcgYXQgMToxNiBBTSwgR29ycnkgRmFp cmh1cnN0ICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVy Zy5hYmRuLmFjLnVrPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBJIHNlZSByZWFsIG1lcml0IGlu IG1vdmluZyBiZXlvbmQgKDEpIGZvciBhbm90aGVyIHJlYXNvbiBpZiB0aGlzIGV4cG9zZXMgYXQg bGVhc3QgY29ubmVjdGlvbiBJRCwgcGFja2V0IG51bWJlciwgcGFja2V0IG51bWJlciBlY2hvIChh c3VtaW5nIG9uZSBjYW4gYWxzbyBkZXJpdmUgKGJlZ2luL2VuZCBvZiBmbG93LCBldGMgZm9yIGEg dHJhZmZpYyBmbG93Ljxicj4NCiZndDs8YnI+DQomZ3Q7IE92ZXIgdGhlIHllYXJzIEkndmUgc2Vl biB0aGUgSUVURiBwcm9kdWNlIHF1aXRlIGEgZmV3ICZxdW90O3RyYW5zcG9ydCZxdW90OyBwcm90 b2NvbHMsIGFuZCB3aGlsZSBlYWNoIG9mIHRoZW0gaGFzIGhhZCBkaWZmZXJlbnQgcmVxdWlyZW1l bnRzIGFuZCBhbWJpdGlvbnMsIEknZCBsaWtlIHRvIG9ic2VydmUgdGhhdCBzdWNjZXNzZnVsIG9u ZXMgb2Z0ZW4gaW5jbHVkZSBhbiBhYmlsaXR5IGZvciBuZXR3b3JrIG9wZXJhdG9ycyBhbmQgaW5k ZXBlbmRlbnQgcmVzZWFyY2hlcnMNCiB0byBib3RoIGdhdGhlciBwZXItZmxvdyB0cmFmZmljIG1l YXN1cmVtZW50cyBhbmQgdG8gdW5kZXJzdGFuZCBwYXRob2xvZ2llcyBvZiBob3cgdHJhZmZpYyBm bG93cyBzaGFyZSBjYXBhY2l0eSBhbmQgdW5kZXJzdGFuZCB3aGVyZSBwcm9ibGVtcyBleGlzdCB3 aXRoaW4gbmV0d29ya3MuIERvaW5nIHRoaXMgd2l0aGluIHRoZSBuZXR3b3JrIHJlbGllcyBvbiB2 aXNpYmlsaXR5IG9mIGF0IGxlYXN0IGZpZWxkcyB3aXRoIHZpc2liaWxpdHkgb2YgYmFzaWMNCiBm bG93IGluZm9ybWF0aW9uIGluIHRoZSBwYXlsb2FkLjxicj4NCiZndDs8YnI+DQomZ3Q7IEl0J3Mg T0sgZnJvIG1lIHRvaGF2ZSBydWxlcyBhYm91dCB3aGV0aGVyIHBhY2tldCBudW1iZXJzIGhhdmUg dG8gbW9ub3RvbWljYWxseSBpbmNyZWFzZSB0byBiZSB1c2VmdWwgYXQgYSByZWNlaXZlciwgd2hl dGhlciByZWNlaXZlcnMgY2FuIHVzZWZ1bGx5IHVzZSByZS1yZXNlcXVlbmNlZCBwYWNrZXRzLCBv ciBkYXRhIHdpdGggZ2FwcywgZXRjLiBFdmVuIHdpdGggdGhlc2UgY29uc3RyYWludHMsIGEgc2V0 IG9mIHZpc2libGUgZmllbGRzIGNvdWxkDQogc3RpbGwgb3Blbi11cCBkYXRhIG9uIHdoZXRoZXIg bXkgY3VycmVudCBuZXR3b3JrIGxpbmsgaXMgc2VlaW5nIG1vcmUgJnF1b3Q7Z2FwcyZxdW90Oywg JnF1b3Q7cmVzZXF1ZW5jaW5nJnF1b3Q7LCAmcXVvdDt3aGF0ZXZlciZxdW90OyBjb21wYXJlZCB0 byBhIG1lYXN1cmVtZW50IGF0IGFub3RoZXIgdGltZSBvZiBkYXksIG9yIGFub3RoZXIgdHlwZSBv ZiBuZXR3b3JrIGxpbmsgLSBhbGwgb2Ygd2hpY2ggY2FuIGJlIGhlbHBmdWwgaW4gdW5kZXJzdGFu ZGluZyBob3cgdG8gb3BlcmF0ZSBteSBuZXR3b3JrLA0KIGFuZCB3aGV0aGVyIHRoaXMgdHJhZmZp YyBpcyBjby1leGlzdGluZyB3aXRoIG90aGVyIHRyYW5zcG9ydCBzZXJ2aWNlcy4gQXMgd2UgbG9v ayBhaGVhZCB0byBuZXR3b3JrcyB3aXRoIGdyZWF0ZXIgdmFyaWFiaWxpdHkgKDVHPyksIG1vcmUg cmVvcmRlcmluZywgb3Igd2lkZXIgbWl4ZXMgb2YgdHJhZmZpYyBhbmQgZm9yd2FyZGluZyBydWxl cywgdGhpcyBiZWNvbWVzIG1vcmUgaW1wb3J0YW50LCBub3QgbGVzcy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBHb3JyeTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAzMS8wMS8yMDE3IDAw OjM1LCBNYXJ0aW4gVGhvbXNvbiB3cm90ZTo8YnI+DQomZ3Q7IE9uIDMxIEphbnVhcnkgMjAxNyBh dCAwNDowOCwgTWlyamEgS8O8aGxld2luZDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpt aXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5l dGh6LmNoPC9hPiZndDsmbmJzcDsgd3JvdGU6PGJyPg0KJmd0OyAtIHBhY2tldCBudW1iZXIgKGNh biBiZSB1c2VkIGZvciBsb3NzIGRldGVjdGlvbiBvZiBsb3NzZXMgdGhhdCBvY2N1cnJlZCBiZWZv cmUgdGhlIG9ic2VydmF0aW9uIHBvaW50IGlmIGluY3JlYXNlZCBsaW5lYXJseSB3aXRob3V0IGdh cHMpLCBhbmQ8YnI+DQomZ3Q7IE9uIHRoaXMgcG9pbnQsIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u cyBza2lwIHBhY2tldCBudW1iZXJzPGJyPg0KJmd0OyBwZXJpb2RpY2FsbHkuJm5ic3A7IFRoYXQg bG9va3MgbGlrZSBsb3NzIHRvIHRoZSBvdGhlciBzaWRlIChvciB0aGUgcGF0aCksPGJyPg0KJmd0 OyBidXQgZXZlbiBzcHVyaW91cyBsb3NzZXMgZG9uJ3QgaGF2ZSBhIGJpdCBpbXBhY3Qgb24gdGhp bmdzIGxpa2U8YnI+DQomZ3Q7IGNvbmdlc3Rpb24gY29udHJvbCBpZiB0aGV5IGFyZSByYXJlIGVu b3VnaC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbmUgdGhpbmcgdGhhdCB3ZSd2ZSBkaXNjdXNzZWQg aXMgdGhlIHVzZSBvZiBnYXBzIHRvIHZlcmlmeSBwYWNrZXQ8YnI+DQomZ3Q7IHJlY2VpcHQgYWZ0 ZXIgYSBjb25uZWN0aW9uIG1pZ3JhdGlvbi4mbmJzcDsgQW4gZW5kcG9pbnQgdGhhdCBkZXRlY3Rz IGEgbW92ZTxicj4NCiZndDsgY2FuIHN0YXJ0IHNraXBwaW5nIG1vcmUgYWdncmVzc2l2ZWx5IHRv IHByb3RlY3QgYWdhaW5zdCBvcHRpbWlzdGljIGFjazxicj4NCiZndDsgYXR0YWNrcyBvbiB0aGF0 IG5ldyBwYXRoLiZuYnNwOyBJIGd1ZXNzIHRoYXQgeW91IGNvdWxkIGFyZ3VlIHRoYXQgZWNob2lu ZyBhPGJyPg0KJmd0OyBwYWNrZXQgbnVtYmVyIGFjaGlldmVzIHRoZSBzYW1lIGVmZmVjdCBtb3Jl IGVmZmljaWVudGx5LCBidXQgd2Ugd291bGQ8YnI+DQomZ3Q7IG5lZWQgdG8gYXNzZXNzIHRoYXQg aW4gdGhlIGNvbnRleHQgb2YgdGhlIGJ5dGVzIGl0IHdvdWxkIGV4cGVuZDxicj4NCiZndDsgb3Zl cmFsbC48YnI+DQomZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR03MB25333BC3314F3776D4170B4FB64A0CY4PR03MB2533namp_-- From nobody Tue Jan 31 12: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 43EDC129A40 for ; Tue, 31 Jan 2017 12:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 lzdxb94xJzLs for ; Tue, 31 Jan 2017 12:19:47 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F1A129A3C for ; Tue, 31 Jan 2017 12:19:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vCd0K2mXszMpbg; Tue, 31 Jan 2017 21:19:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8JiC74WL-Sv; Tue, 31 Jan 2017 21:19:44 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC28DE.dip0.t-ipconnect.de [93.236.40.222]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 31 Jan 2017 21:19:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Ossification From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 31 Jan 2017 21:19:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9ECBC1BC-B690-4334-BDC0-7CE815D962C5@tik.ee.ethz.ch> References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> <2EDD31AA-D768-4E7F-A31D-A850945D008C@tik.ee.ethz.ch> To: Christian Huitema X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "Gorry \(erg\)" , Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:19:49 -0000 Hi Christian, we discussed most of these cases at the interim and also discussed a = possible solution where the client could ask the server for a next = connection ID that it would use after a mobility event (case 3) and the = server could also provide this new ID to the load balancer (case 4). = However, if the client is not aware of the network change (case 2), it = will just send the old connection ID over the new path which would make = it possible to link these two connections. This part is hard to avoid. = Also note that even if we would not have a connection ID at all, the = (random) packet number would provide similar opportunities for linkage. = I believe the conclusion (so far) was that the charter requirement is to = be not worth than (MP)TCP and as such it=E2=80=99s probably worth to = have a connection ID to support use case 2-4 (agree that 1 is no use = case). However, this will need further discussion in Chicago! Mirja > Am 31.01.2017 um 21:02 schrieb Christian Huitema = : >=20 > On 1/31/2017 9:24 AM, Mirja K=C3=BChlewind wrote: > ... >> That=E2=80=99s my point. Knowing that the position of the connection = ID will ossify, we should maybe consider to actively decide that we want = to support that and design the protocol respectively. >=20 > Maybe we should start with an analysis of what the connection ID is = used for, and determine which of these uses requires bytes in the = header, versus for example an option in a connect message. And maybe how = many bytes. So far the candidates are: >=20 > 1) Demultiplexing at receiver. Arguably, this can be also be done by = just looking at port numbers. >=20 > 2) Reconnecting after a NAT mapping change. Without a connection ID, = this would have to be treated like any other mobility event. >=20 > 3) Reconnecting after a mobility event. The connection ID provides a = simple mechanism. Without connection ID, we would have to do an explicit = connection resume, similar to TLS resume. >=20 > 4) Load balancing over several paths, as in TCP multipath. Connection = ID enables a simple solution, perhaps too simple. TCP multipath manages = separate sequence numbers and congestion controls for each path, and to = do that we would need different connection ID for each path. >=20 > For mobility and multipath, having the connection ID in all packets = has a substantial privacy downside, so arguably we will need to develop = "something like TLS resume" in any case. So maybe we need to think = really hard about these issues! >=20 > -- Christian Huitema From nobody Tue Jan 31 12:22: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 A795A129A55 for ; Tue, 31 Jan 2017 12:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 1GGPaW9sAMq3 for ; Tue, 31 Jan 2017 12:22:43 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 60B03129A52 for ; Tue, 31 Jan 2017 12:22:43 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 8C0F11B00055; Tue, 31 Jan 2017 22:20:08 +0000 (GMT) Message-ID: <5890F1F4.40100@erg.abdn.ac.uk> Date: Tue, 31 Jan 2017 21:22:12 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jana Iyengar Subject: Re: Ossification References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Martin Thomson , IETF QUIC WG , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-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, 31 Jan 2017 20:22:45 -0000 On 31/01/2017 19:55, Jana Iyengar wrote: > I'm loathe to increase the QUIC packet header size to avoid > increasingly additional overhead. That wasn't specifically what I asked. > I agree that (1) seems fundamentally hard to do without substantial > computational cost and other overhead, so I'd be fine with exposing > some things. OK. > I think this is expected to be discussed in Chicago anyways, FWIW. > > That said, my expectation is that there are three types of middleboxes > that we want to address: > (i) Those that want to separate QUIC connections from unwarranted traffic; > (ii) Those that want to track QUIC connection state; and > (iii) Those that want to firewall certain services (eg., WebRTC). > Middleboxes are interested in blocking services, not the transport. > My point was related to operating a network and allowing independent research on traffic. Maybe that's a fourth case? - tracking state seems rather more than passive monitoring. > (iii) is basically solved using the same signals that middleboxes use > today: server port number. Blocking UDP to port 443 effectively blocks > use of QUIC for HTTPS. > > For (i) and (ii), if middleboxes are being modified to detect QUIC, I > don't think they'd have trouble going through the state machine and > remembering where the QUIC connection ID falls. I appreciate your > concern about ossification of specific versions, but if there are > ossified middleboxes that need to track connection state (type (iii) > above), then we're stuck with the position of the connection ID anyways. > > Specifying the version or sending a magic number in each packet has > quantifiable overhead cost but the benefits are unknown, and I'd be > inclined against them. For in-network measurements, as we've discussed > previously, there may be value in sending the "largest observed" in > that header. > I didn't ask for a magic number either, assuming that packet numbers were a feature that would be in every version, largest observed would I expect be helpful here. Gorry > On Tue, Jan 31, 2017 at 1:16 AM, Gorry Fairhurst > wrote: > > I see real merit in moving beyond (1) for another reason if this > exposes at least connection ID, packet number, packet number echo > (asuming one can also derive (begin/end of flow, etc for a traffic > flow. > > Over the years I've seen the IETF produce quite a few "transport" > protocols, and while each of them has had different requirements > and ambitions, I'd like to observe that successful ones often > include an ability for network operators and independent > researchers to both gather per-flow traffic measurements and to > understand pathologies of how traffic flows share capacity and > understand where problems exist within networks. Doing this within > the network relies on visibility of at least fields with > visibility of basic flow information in the payload. > > It's OK for me to have rules about whether packet numbers have to > monotomically increase to be useful at a receiver, whether > receivers can usefully use re-resequenced packets, or data with > gaps, etc. Even with these constraints, a set of visible fields > could still open-up data on whether my current network link is > seeing more "gaps", "resequencing", "whatever" compared to a > measurement at another time of day, or another type of network > link - all of which can be helpful in understanding how to operate > my network, and whether this traffic is co-existing with other > transport services. As we look ahead to networks with greater > variability (5G?), more reordering, or wider mixes of traffic and > forwarding rules, this becomes more important, not less. > > Gorry > > > On 31/01/2017 00:35, Martin Thomson wrote: > > On 31 January 2017 at 04:08, Mirja Kühlewind > > wrote: > > - packet number (can be used for loss detection of losses > that occurred before the observation point if increased > linearly without gaps), and > > On this point, existing implementations skip packet numbers > periodically. That looks like loss to the other side (or the > path), > but even spurious losses don't have a bit impact on things like > congestion control if they are rare enough. > > One thing that we've discussed is the use of gaps to verify packet > receipt after a connection migration. An endpoint that > detects a move > can start skipping more aggressively to protect against > optimistic ack > attacks on that new path. I guess that you could argue that > echoing a > packet number achieves the same effect more efficiently, but > we would > need to assess that in the context of the bytes it would expend > overall. > > > From nobody Tue Jan 31 12:50: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 A3EB912956A for ; Tue, 31 Jan 2017 12:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVDLKFVpWfQm for ; Tue, 31 Jan 2017 12:50:46 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0120.outbound.protection.outlook.com [104.47.40.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55BC129AB1 for ; Tue, 31 Jan 2017 12:50:41 -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=xtqfw+TUPRyDchbBCQF8VVmyLZ9B/KpxYjPSVyU6tTA=; b=CsitXmXemvTy7wWKSxzsIXR33nipgQQhOdu+CFu9Qb4FXuf8/isGJ+oC97hov1Q6brcTALoqKFsngwoZWC0fdiLYDpGi9T2reKFlTruZtTrEFY2ixmqVav61+huKwChS/M8sh1+sfMH+ROnmhScglk+mTn+gcw8E1Q7LE5Fc3HI= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 31 Jan 2017 20:50:37 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.026; Tue, 31 Jan 2017 20:50:37 +0000 From: Mike Bishop To: Charles 'Buck' Krasic , Kazuho Oku Subject: RE: Splitting QPACK Thread-Topic: Splitting QPACK Thread-Index: AdJ30+1U3c1mTWZdTYamExCwb70oCACzn2/wAAELOgAAARWsoAAua8MAACFVcoAAAD2LAAAGDrKA Date: Tue, 31 Jan 2017 20:50:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:8::51f] x-ms-office365-filtering-correlation-id: 444bf45b-0af4-4999-15d4-08d44a1acf7d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:IlduxSMbpSGNAZUkb1sCzZpj1y5kkEEs84vY36mRBVvORVJYGEVdkpRs0keISgG8GY1JSIVfpUPqOPi2zAmKTfnvpuUIRe6ozH82zy0ctXGPkndSVPntidOi/HZSyvGvJvcKCc70zKpFOYHHTNCqUmP7sw5M3diwvc4V1uqY4rmLQmCL4AbwTUr9dPMKabfW924F19Yivr4tp/+iegBkVkoQ8tJx6llpQFwNSsOO+61YLySJryJMbf0Nqy1gSmx5BSvKcOvxv0NE071cyWIQDIKw+B1kOEh8Hqg+0RGs8xWTq/zI7BlgesXXiPBT9fq5bJhgjzIbxyoUn3tKGLGzKy9pU5bzA3rxeakitHRQL1rtF57HgLElNehZgCnpzr67qA/tTzqYwrmNLCgQ8elzVHwdpRwPBVWFOI72zWHvTB4xsI6G6KdJczczS4K242MNchHYbeFRA9pV4XVxBto+aJX9XVSG7yxePSACUQopnI+EvLVxYL+MOk1jVMwn1ilr0ix/If7HozuM+vEFQippXkxZc44iZDuJRTjXi1Ji+WBdjYDByPYELWRWRtv/nms3 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6042181)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377424004)(199003)(24454002)(189002)(377454003)(52084003)(54356999)(3280700002)(7116003)(3660700001)(106356001)(4326007)(33656002)(53936002)(74316002)(236005)(7736002)(5660300001)(105586002)(8990500004)(2906002)(50986999)(76176999)(102836003)(101416001)(68736007)(19609705001)(6116002)(790700001)(3480700004)(10090500001)(92566002)(6306002)(77096006)(221733001)(7696004)(54896002)(9686003)(25786008)(54906002)(122556002)(86362001)(10290500002)(81156014)(38730400001)(93886004)(81166006)(86612001)(8936002)(2950100002)(99286003)(39060400001)(2900100001)(5005710100001)(8676002)(189998001)(6506006)(55016002)(5001770100001)(97736004)(229853002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708A55D6F2424AC02BCBB39874A0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 20:50:37.6268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:50:51 -0000 --_000_BN6PR03MB2708A55D6F2424AC02BCBB39874A0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBpZiB0aGUgZW5jb2RlciB3YXMgYm90aCBkZXRlcm1pbmVkIG5ldmVyIHRvIEhPTEIgYW5k IGRpZCBpdCB0aGF0IHdheS4gIEkgdGhpbmsgbW9yZSByZWFsaXN0aWMgbWlnaHQgYmUgdG8gc2F5 IHRoYXQgd3JpdGluZyBzb21ldGhpbmcgc21hbGwgdG8gdGhlIGhlYWRlcnMgc3RyZWFtIGFuZCB3 cml0aW5nIHRoZSBmdWxsIGhlYWRlciBzZXQgdG8gdGhlIHJlcXVlc3Qgc3RyZWFtIGF0IHRoZSBz YW1lIHRpbWUsIHRoZXnigJlyZSB2ZXJ5IGxpa2VseSB0byB3aW5kIHVwIGluIHRoZSBzYW1lIHBh Y2tldC4gIERlcGVuZGluZyBvbiB0aGUgaW50ZWdyYXRpb24geW91IGhhdmUgd2l0aCB5b3VyIHRy YW5zcG9ydCBzdGFjaywgdGhlcmUgbWlnaHQgZXZlbiBiZSBhIHdheSBmb3IgYW4gaW1wbGVtZW50 YXRpb24gdG8gZ3VhcmFudGVlIHRoYXQsIGJ1dCB0aGF04oCZcyBiZXlvbmQgdGhlIHNjb3BlIG9m IGEgcHJvdG9jb2wgZG9jdW1lbnQuDQoNCkZyb206IENoYXJsZXMgJ0J1Y2snIEtyYXNpYyBbbWFp bHRvOmNrcmFzaWNAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTcg OTo1MyBBTQ0KVG86IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzogTWlrZSBC aXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+OyBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBT cGxpdHRpbmcgUVBBQ0sNCg0KT25lIG1vcmUgdGhvdWdodC9xdWVzdGlvbiBhYm91dCBhIGRlZGlj YXRlZCBzdHJlYW0gZm9yIHVwZGF0ZXMuICAgIFdvdWxkIGl0IHBlbmFsaXplIHRoZSBjb21wcmVz c2lvbiBvZiBIb0wgYXZvaWRpbmcgZnVydGhlciwgaW4gdGhlIHNlbnNlIHRoYXQgd2hhdCB3b3Vs ZCBiZSBhbiBpbmNyZW1lbnRhbCB1cGRhdGUgdG9kYXkgd291bGQgYmUgYW4gdXBkYXRlIG9uIHRo ZSBjb250cm9sIHN0cmVhbSwgYWxvbmcgd2l0aCBhIGxpdGVyYWwgb24gdGhlIGRhdGEgc3RyZWFt PyAgSS5lLiBtaW5pbXVtIHR3byBsaXRlcmFscyBmb3IgbW9zdCBlbnRyaWVzIGFkZGVkIHRvIHRo ZSB0YWJsZT8NCg0KT24gVHVlLCBKYW4gMzEsIDIwMTcgYXQgOTo0NiBBTSwgQ2hhcmxlcyAnQnVj aycgS3Jhc2ljIDxja3Jhc2ljQGdvb2dsZS5jb208bWFpbHRvOmNrcmFzaWNAZ29vZ2xlLmNvbT4+ IHdyb3RlOg0KDQoNCk9uIE1vbiwgSmFuIDMwLCAyMDE3IGF0IDU6NTIgUE0sIEthenVobyBPa3Ug PGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+PiB3cm90ZToN CjIwMTctMDEtMzAgMTI6NDUgR01UKzA5OjAwIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBt aWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj46DQo+IFll cywgaXQgd291bGQgbWVhbiBicmluZ2luZyBiYWNrIHRoZSBEQVRBIGZyYW1lIGZyb20gSFRUUC8y LiAgR2l2ZW4gdGhhdCB3ZQ0KPiBhbHJlYWR5IGhhdmUgaW50cmEtc3RyZWFtIGZyYW1pbmcgKG9u IG9uZSBzdHJlYW0gb2YgdHdvKSwgdGhhdCBkaWRu4oCZdCBzZWVtDQo+IGxpa2UgYSBiaWcgbG9z cyB0byBtZS4gIEhvd2V2ZXIsIEkgY2FuIGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgcGVyZm9ybWFu Y2UNCj4gZWZmaWNpZW5jaWVzIHRvIGJlIGdhaW5lZCBmcm9tIGJlaW5nIGFibGUgdG8gZGlzcGVu c2Ugd2l0aCBmcmFtaW5nIG9uY2UgeW91DQo+IGdldCB0byB0aGUgYm9keS4NCg0KTXkgdHdvIGNl bnRzIGdvIHRvIHVzaW5nIHNpbmdsZSBzdHJlYW0gZm9yIGJvdGggaGVhZGVycyBhbmQgYm9keSwN CnNpbmNlIEknZCBiZSB3b3JyaWVkIG9mIHRoZSBtYXhpbXVtIGFtb3VudCBvZiBtZW1vcnkgdGhh dCB3b3VsZCBiZQ0KY29uc3VtZWQgYnkgdGhlIHBlci1zdHJlYW0gcmVjZWl2ZSB3aW5kb3dzLg0K DQpJZiB3ZSBjb3VsZCBzZW5kIGhlYWRlcnMgYW5kIGJvZHkgb24gYSBzaW5nbGUgc3RyZWFtIHRo ZW4gaXQgd291bGQNCm1lYW4gdGhhdCB0aGUgbWF4aW11bSBudW1iZXIgb2Ygc3RyZWFtcyB0aGF0 IGFuIGVuZHBvaW50IGJlY29tZXMgaGFsZg0Kd2hlbiBjb21wYXJlZCB0byBjdXJyZW50IGFwcHJv YWNoLiBUaGF0IHdvdWxkIGluIHR1cm4gbWVhbiB0aGF0IHRoZQ0KbWF4aW11bSBhbW91bnQgb2Yg bWVtb3J5IHRoYXQgbmVlZHMgdG8gYmUgYWxsb2NhdGVkIGZvciB0aGUgcmVjZWl2ZQ0Kd2luZG93 cyBiZWNvbWVzIGhhbGYsIG9yIHRoYXQgdGhlIHNpemUgb2YgcGVyLXN0cmVhbSByZWNlaXZlIHdp bmRvd3MNCmNhbiBiZSBkb3VibGVkIHdoaWxlIGtlZXBpbmcgdGhlIG1heGltdW0gc2FtZSB0byB0 aGUgY3VycmVudCBkcmFmdC4NCg0KV2hlbiBtZW1vcnkgaXMgYSBjb25jZXJuLCBJIHRoaW5rIGFu IGltcGxlbWVudGF0aW9uIHNob3VsZCBjb25zaWRlciBhdXRvLXR1bmluZyB0aGUgcmVjZWl2ZSB3 aW5kb3cgc2l6ZXMuICAgIFRoZSBHb29nbGUgUVVJQyBjb2RlIGRvZXMgdGhpcy4gICAgICBVbmRl ciBzdWNoIGEgcmVnaW1lLCB0aGUgdG90YWwgYW1vdW50IG9mIG1lbW9yeSB1c2VkIGJ5IHJlY2Vp dmUgYnVmZmVycyBoYXMgbW9yZSB0byBkbyB3aXRoIGFnZ3JlZ2F0ZSBCRFAgdGhhbiBudW1iZXIg b2Ygc3RyZWFtcy4NCg0KPg0KPg0KPiBGcm9tOiBSeWFuIEhhbWlsdG9uIFttYWlsdG86cmNoQGdv b2dsZS5jb208bWFpbHRvOnJjaEBnb29nbGUuY29tPl0NCj4gU2VudDogU3VuZGF5LCBKYW51YXJ5 IDI5LCAyMDE3IDc6MTIgUE0NCj4gVG86IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNy b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4NCj4gQ2M6IElF VEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQo+IFN1Ympl Y3Q6IFJlOiBTcGxpdHRpbmcgUVBBQ0sNCj4NCj4NCj4NCj4NCj4NCj4gT24gU3VuLCBKYW4gMjks IDIwMTcgYXQgNjo0NiBQTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+Pg0KPiB3cm90ZToNCj4NCj4g QWxzbywgaWYgd2UgZ28gdGhpcyB3YXksIHRoZSByZW1haW5pbmcgcmVhc29ucyB0byBzZXBhcmF0 ZSBoZWFkZXJzIGFuZCBkYXRhDQo+IHNlZW0gdG8gaGF2ZSBkaXNhcHBlYXJlZCwgYW5kIHdlIG1p Z2h0IGJlIGFibGUgdG8gZ2V0IGRvd24gdG8gb25lIHN0cmVhbSBwZXINCj4gcmVxdWVzdC4NCj4N Cj4NCj4NCj4gV2UnZCBzdGlsbCBuZWVkIHNvbWUgbWVjaGFuaXNtLCB3aXRoaW4gYSBzdHJlYW0s IHRvIGRlbGltaXQgaGVhZGVycyBkYXRhDQo+IGZyb20gYm9keSBkYXRhLCByaWdodD8gVXNpbmcg dHdvIFFVSUMgc3RyZWFtcyBzb2x2ZXMgdGhpcyBwcm9ibGVtIG5pY2VseS4gSQ0KPiBkb24ndCBs b3ZlIGFkZGluZyBtb3JlIGludHJhLXN0cmVhbSBmcmFtaW5nLCBpZiB3ZSBjYW4gYXZvaWQgaXQu DQo+DQo+DQoNCg0KLS0NCkthenVobyBPa3UNCg0KDQoNCi0tDQpDaGFybGVzICdCdWNrJyBLcmFz aWMgfCBTb2Z0d2FyZSBFbmdpbmVlciB8IGNrcmFzaWNAZ29vZ2xlLmNvbTxtYWlsdG86Y2tyYXNp Y0Bnb29nbGUuY29tPiB8ICsxICg0MDgpIDQxMi0xMTQxPHRlbDooNDA4KSUyMDQxMi0xMTQxPg0K DQoNCg0KLS0NCkNoYXJsZXMgJ0J1Y2snIEtyYXNpYyB8IFNvZnR3YXJlIEVuZ2luZWVyIHwgY2ty YXNpY0Bnb29nbGUuY29tPG1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20+IHwgKzEgKDQwOCkgNDEy LTExNDENCg== --_000_BN6PR03MB2708A55D6F2424AC02BCBB39874A0BN6PR03MB2708namp_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubS03MjQ1OTUzNTMwNTIwNjQ4 NDEyaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fLTcyNDU5NTM1MzA1MjA2NDg0MTJob2VuemI7 fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ZZXMsIGlmIHRoZSBlbmNvZGVyIHdhcyBib3RoIGRldGVybWluZWQgbmV2ZXIgdG8g SE9MQiBhbmQgZGlkIGl0IHRoYXQgd2F5LiZuYnNwOyBJIHRoaW5rIG1vcmUgcmVhbGlzdGljIG1p Z2h0IGJlIHRvIHNheSB0aGF0IHdyaXRpbmcgc29tZXRoaW5nIHNtYWxsIHRvIHRoZSBoZWFkZXJz IHN0cmVhbSBhbmQgd3JpdGluZyB0aGUgZnVsbCBoZWFkZXIgc2V0IHRvIHRoZSByZXF1ZXN0IHN0 cmVhbSBhdCB0aGUgc2FtZSB0aW1lLA0KIHRoZXnigJlyZSB2ZXJ5IGxpa2VseSB0byB3aW5kIHVw IGluIHRoZSBzYW1lIHBhY2tldC4mbmJzcDsgRGVwZW5kaW5nIG9uIHRoZSBpbnRlZ3JhdGlvbiB5 b3UgaGF2ZSB3aXRoIHlvdXIgdHJhbnNwb3J0IHN0YWNrLCB0aGVyZSBtaWdodCBldmVuIGJlIGEg d2F5IGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0byBndWFyYW50ZWUgdGhhdCwgYnV0IHRoYXTigJlz IGJleW9uZCB0aGUgc2NvcGUgb2YgYSBwcm90b2NvbCBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IENoYXJsZXMgJ0J1Y2snIEtyYXNpYyBbbWFpbHRvOmNrcmFz aWNAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDMxLCAy MDE3IDk6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFp bC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IFJ5 YW4gSGFtaWx0b24gJmx0O3JjaEBnb29nbGUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogU3BsaXR0aW5nIFFQQUNLPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgbW9y ZSB0aG91Z2h0L3F1ZXN0aW9uIGFib3V0IGEgZGVkaWNhdGVkIHN0cmVhbSBmb3IgdXBkYXRlcy4g Jm5ic3A7ICZuYnNwO1dvdWxkIGl0IHBlbmFsaXplIHRoZSBjb21wcmVzc2lvbiBvZiBIb0wgYXZv aWRpbmcgZnVydGhlciwgaW4gdGhlIHNlbnNlIHRoYXQgd2hhdCB3b3VsZCBiZSBhbiBpbmNyZW1l bnRhbCB1cGRhdGUgdG9kYXkgd291bGQgYmUgYW4gdXBkYXRlIG9uIHRoZSBjb250cm9sIHN0cmVh bSwgYWxvbmcgd2l0aA0KIGEgbGl0ZXJhbCBvbiB0aGUgZGF0YSBzdHJlYW0/Jm5ic3A7IEkuZS4g bWluaW11bSB0d28gbGl0ZXJhbHMgZm9yIG1vc3QgZW50cmllcyBhZGRlZCB0byB0aGUgdGFibGU/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEph biAzMSwgMjAxNyBhdCA5OjQ2IEFNLCBDaGFybGVzICdCdWNrJyBLcmFzaWMgJmx0OzxhIGhyZWY9 Im1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5ja3Jhc2ljQGdvb2ds ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBKYW4gMzAsIDIwMTcgYXQgNTo1MiBQTSwgS2F6dWhvIE9rdSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1 aG9va3VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNy0wMS0zMCAxMjo0NSBHTVQmIzQzOzA5OjAwIE1p a2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8 YnI+DQomZ3Q7IFllcywgaXQgd291bGQgbWVhbiBicmluZ2luZyBiYWNrIHRoZSBEQVRBIGZyYW1l IGZyb20gSFRUUC8yLiZuYnNwOyBHaXZlbiB0aGF0IHdlPGJyPg0KJmd0OyBhbHJlYWR5IGhhdmUg aW50cmEtc3RyZWFtIGZyYW1pbmcgKG9uIG9uZSBzdHJlYW0gb2YgdHdvKSwgdGhhdCBkaWRu4oCZ dCBzZWVtPGJyPg0KJmd0OyBsaWtlIGEgYmlnIGxvc3MgdG8gbWUuJm5ic3A7IEhvd2V2ZXIsIEkg Y2FuIGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgcGVyZm9ybWFuY2U8YnI+DQomZ3Q7IGVmZmljaWVu Y2llcyB0byBiZSBnYWluZWQgZnJvbSBiZWluZyBhYmxlIHRvIGRpc3BlbnNlIHdpdGggZnJhbWlu ZyBvbmNlIHlvdTxicj4NCiZndDsgZ2V0IHRvIHRoZSBib2R5Ljxicj4NCjxicj4NCk15IHR3byBj ZW50cyBnbyB0byB1c2luZyBzaW5nbGUgc3RyZWFtIGZvciBib3RoIGhlYWRlcnMgYW5kIGJvZHks PGJyPg0Kc2luY2UgSSdkIGJlIHdvcnJpZWQgb2YgdGhlIG1heGltdW0gYW1vdW50IG9mIG1lbW9y eSB0aGF0IHdvdWxkIGJlPGJyPg0KY29uc3VtZWQgYnkgdGhlIHBlci1zdHJlYW0gcmVjZWl2ZSB3 aW5kb3dzLjxicj4NCjxicj4NCklmIHdlIGNvdWxkIHNlbmQgaGVhZGVycyBhbmQgYm9keSBvbiBh IHNpbmdsZSBzdHJlYW0gdGhlbiBpdCB3b3VsZDxicj4NCm1lYW4gdGhhdCB0aGUgbWF4aW11bSBu dW1iZXIgb2Ygc3RyZWFtcyB0aGF0IGFuIGVuZHBvaW50IGJlY29tZXMgaGFsZjxicj4NCndoZW4g Y29tcGFyZWQgdG8gY3VycmVudCBhcHByb2FjaC4gVGhhdCB3b3VsZCBpbiB0dXJuIG1lYW4gdGhh dCB0aGU8YnI+DQptYXhpbXVtIGFtb3VudCBvZiBtZW1vcnkgdGhhdCBuZWVkcyB0byBiZSBhbGxv Y2F0ZWQgZm9yIHRoZSByZWNlaXZlPGJyPg0Kd2luZG93cyBiZWNvbWVzIGhhbGYsIG9yIHRoYXQg dGhlIHNpemUgb2YgcGVyLXN0cmVhbSByZWNlaXZlIHdpbmRvd3M8YnI+DQpjYW4gYmUgZG91Ymxl ZCB3aGlsZSBrZWVwaW5nIHRoZSBtYXhpbXVtIHNhbWUgdG8gdGhlIGN1cnJlbnQgZHJhZnQuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XaGVuIG1lbW9yeSBpcyBhIGNvbmNlcm4sIEkgdGhpbmsgYW4gaW1w bGVtZW50YXRpb24gc2hvdWxkIGNvbnNpZGVyIGF1dG8tdHVuaW5nIHRoZSByZWNlaXZlIHdpbmRv dyBzaXplcy4gJm5ic3A7ICZuYnNwO1RoZSBHb29nbGUgUVVJQyBjb2RlIGRvZXMgdGhpcy4gJm5i c3A7ICZuYnNwOyAmbmJzcDtVbmRlciBzdWNoIGEgcmVnaW1lLCB0aGUgdG90YWwgYW1vdW50IG9m IG1lbW9yeSB1c2VkIGJ5IHJlY2VpdmUgYnVmZmVycyBoYXMgbW9yZSB0byBkbyB3aXRoDQogYWdn cmVnYXRlIEJEUCB0aGFuIG51bWJlciBvZiBzdHJlYW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEZyb206IFJ5 YW4gSGFtaWx0b24gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cmNoQGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5yY2hAZ29vZ2xlLmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiBTdW5kYXksIEph bnVhcnkgMjksIDIwMTcgNzoxMiBQTTxicj4NCiZndDsgVG86IE1pa2UgQmlzaG9wICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IElFVEYg UVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBTcGxpdHRpbmcg UVBBQ0s8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgT24gU3VuLCBKYW4gMjksIDIwMTcgYXQgNjo0NiBQTSwgTWlrZSBCaXNob3AgJmx0 OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9i bGFuayI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyB3cm90 ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbHNvLCBpZiB3ZSBnbyB0aGlzIHdheSwgdGhlIHJlbWFp bmluZyByZWFzb25zIHRvIHNlcGFyYXRlIGhlYWRlcnMgYW5kIGRhdGE8YnI+DQomZ3Q7IHNlZW0g dG8gaGF2ZSBkaXNhcHBlYXJlZCwgYW5kIHdlIG1pZ2h0IGJlIGFibGUgdG8gZ2V0IGRvd24gdG8g b25lIHN0cmVhbSBwZXI8YnI+DQomZ3Q7IHJlcXVlc3QuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBXZSdkIHN0aWxsIG5lZWQgc29tZSBtZWNoYW5pc20sIHdpdGhpbiBh IHN0cmVhbSwgdG8gZGVsaW1pdCBoZWFkZXJzIGRhdGE8YnI+DQomZ3Q7IGZyb20gYm9keSBkYXRh LCByaWdodD8gVXNpbmcgdHdvIFFVSUMgc3RyZWFtcyBzb2x2ZXMgdGhpcyBwcm9ibGVtIG5pY2Vs eS4gSTxicj4NCiZndDsgZG9uJ3QgbG92ZSBhZGRpbmcgbW9yZSBpbnRyYS1zdHJlYW0gZnJhbWlu ZywgaWYgd2UgY2FuIGF2b2lkIGl0Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBjbGFzcz0ibS03MjQ1OTUzNTMwNTIw NjQ4NDEyaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS08L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS03MjQ1OTUz NTMwNTIwNjQ4NDEyaG9lbnpiIj5LYXp1aG8gT2t1PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxzcGFuIGNsYXNzPSJo b2VuemIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8 L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1 O2JvcmRlcjpzb2xpZCAjRDUwRjI1IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPkNoYXJsZXMgJ0J1Y2sn IEtyYXNpYyZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpz b2xpZCAjMzM2OUU4IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwO1NvZnR3YXJlDQogRW5naW5l ZXImbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQg IzAwOTkzOSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86Y2tyYXNp Y0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2tyYXNpY0Bnb29nbGUuY29tPC9hPiZuYnNw O3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjRUVCMjEx IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwOzxhIGhyZWY9InRlbDooNDA4KSUyMDQxMi0xMTQx IiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxDQogKDQwOCkgNDEyLTExNDE8L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICNENTBGMjUgMS41cHQ7cGFkZGluZzoy LjBwdCI+Q2hhcmxlcyAnQnVjaycgS3Jhc2ljJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICMzMzY5RTggMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5i c3A7U29mdHdhcmUNCiBFbmdpbmVlciZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NTU1NTU1O2JvcmRlcjpzb2xpZCAjMDA5OTM5IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwOzxh IGhyZWY9Im1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5ja3Jhc2lj QGdvb2dsZS5jb208L2E+Jm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7 Ym9yZGVyOnNvbGlkICNFRUIyMTEgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7JiM0MzsxDQog KDQwOCkgNDEyLTExNDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708A55D6F2424AC02BCBB39874A0BN6PR03MB2708namp_-- From nobody Tue Jan 31 12:54: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 9D93A129A75 for ; Tue, 31 Jan 2017 12:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5bs7ZpjMWga for ; Tue, 31 Jan 2017 12:54:36 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEEE12956A for ; Tue, 31 Jan 2017 12:54:35 -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=5MZdwT+zIW7DTQIQ7GGLIpmNWy5dq44l9f+DRncs5vU=; b=pBbjhQAqYHcOoik2nDQ5dxbHhgAbD/N4TRI/4JGfGEnC8fc+lO0b0Mk/B98FXcktGqZVjhe6/va+N6PA76gU/kt5+MmA+YYPeUKt1UQwH0BR1TZ/AWDlQu7V2yJu5RkNFK/fTuAN0O6Gjewsm5g61UqZD6/XZe0ltoIhnP64tEc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 31 Jan 2017 20:54:33 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.026; Tue, 31 Jan 2017 20:54:32 +0000 From: Mike Bishop To: Jana Iyengar , "Gorry (erg)" Subject: RE: Ossification Thread-Topic: Ossification Thread-Index: AQHSext/BGE1/5djsEmnzKh7PFU5BKFRvaqAgACRa4CAAKHEAIAAIJoQ Date: Tue, 31 Jan 2017 20:54:32 +0000 Message-ID: References: <3FBB949C-6CC2-41D1-90E3-5C555640A115@tik.ee.ethz.ch> <589055D5.5090008@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:8::51f] x-ms-office365-filtering-correlation-id: 254684dd-da5c-41d2-7a2c-08d44a1b5bb5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:cZGD7JdkeahL3fLRm/KujgT7Q0qJM762dLn+Yryu0YqdZkLi1tSolQHaCFfO/u7npmWzve2/jZAxQ9vIx7rUZ8mm0nHO5Eoj7O31X3RtrR7eEfq4pQ5Ow10YI9BHz/JvuGh9dQ065+omQzZmOUhxK8J7SCAcAyVxwP1eOcQwaRUg/x/QnRh8xw0bj22Hz2OCTfWU5UNuJQQ6XiDsfqLnptGNDdilWgII/5mbDZnn4+RPyVoAvp6PvlbHwKL8eI92y7etMI3EVwQMVM8oufNH1C6fmmey9ED9lb5ep+pdlSYSpkOayXXAkq+RXh1QNDSabc1p76CYvAEShuj0uBZ4PuE/cV2CIi98E1jyiEURKCcDFx8XrQWBM/JEsbPLnUki01UHTqYHq7BZDwz5ZveqPbV4uf5MCqHhBZg6pw+c6dXX2bZM8ikYcB7yW7HuhJ+IRYv3RGUsoVXZV0ziqUHq/svcS+7YV/3J71QKVDOoLMj+s/wnPVN1hlY3y+iUz37GpaGJuU9Dp4SQUm34WGFelVUTPRd1J5/4kyU/a1hXFYWEOXLl+jP7B2eT744vglfo x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39450400003)(39410400002)(199003)(24454002)(189002)(377454003)(54356999)(3280700002)(7116003)(3660700001)(106356001)(4326007)(33656002)(106116001)(53936002)(74316002)(236005)(7736002)(5660300001)(105586002)(8990500004)(2906002)(50986999)(76176999)(102836003)(101416001)(68736007)(19609705001)(6116002)(790700001)(3480700004)(10090500001)(92566002)(6306002)(77096006)(221733001)(7696004)(54896002)(9686003)(25786008)(54906002)(122556002)(86362001)(10290500002)(81156014)(38730400001)(93886004)(81166006)(86612001)(8936002)(2950100002)(99286003)(39060400001)(2900100001)(5005710100001)(8676002)(189998001)(6506006)(55016002)(5001770100001)(97736004)(229853002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708A10A97706770EA8A0CB0874A0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 20:54:32.7773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: Martin Thomson , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:54:38 -0000 --_000_BN6PR03MB2708A10A97706770EA8A0CB0874A0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIChpaWkpLCBJIGRvbuKAmXQgdGhpbmsgd2XigJlyZSB0aGF0IG9zc2lmaWVkIG9u IFVEUCB5ZXQuICBIVFRQL1FVSUMgZG9lc27igJl0IHJlc2VydmUgYSBVRFAgcG9ydCBudW1iZXIu ICBZb3Ugb25seSBmaW5kIG91dCBhYm91dCB0aGUgaG9zdC9wb3J0IHRocm91Z2ggdGhlIEFsdC1T dmMgYWR2ZXJ0aXNlbWVudCwgYW5kIHRoYXQgY2FuIGFkdmVydGlzZSBhbnkgcG9ydCBpdCBsaWtl cy4gIFRoZXJlIG1heSBiZSBhIGNvbnZlbnRpb24gdGhhdCBzZXJ2ZXJzIHVzZSA6NDQz4oCmLiAg QnV0IHRoZW4gYWdhaW4sIGl0IG1pZ2h0IGJlIHdvcnRoIGF2b2lkaW5nIHRoYXQgY29udmVudGlv biBpZiBpdCBoZWxwcyBtaW5pbWl6ZSBvc3NpZmljYXRpb24uDQoNCkZyb206IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6 IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTcgMTA6NTUgQU0NClRvOiBHb3JyeSAoZXJnKSA8Z29y cnlAZXJnLmFiZG4uYWMudWs+DQpDYzogTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2lu ZEB0aWsuZWUuZXRoei5jaD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBU aG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogT3NzaWZpY2F0 aW9uDQoNCkknbSBsb2F0aGUgdG8gaW5jcmVhc2UgdGhlIFFVSUMgcGFja2V0IGhlYWRlciBzaXpl IHRvIGF2b2lkIGluY3JlYXNpbmdseSBhZGRpdGlvbmFsIG92ZXJoZWFkLiBJIGFncmVlIHRoYXQg KDEpIHNlZW1zIGZ1bmRhbWVudGFsbHkgaGFyZCB0byBkbyB3aXRob3V0IHN1YnN0YW50aWFsIGNv bXB1dGF0aW9uYWwgY29zdCBhbmQgb3RoZXIgb3ZlcmhlYWQsIHNvIEknZCBiZSBmaW5lIHdpdGgg ZXhwb3Npbmcgc29tZSB0aGluZ3MuIEkgdGhpbmsgdGhpcyBpcyBleHBlY3RlZCB0byBiZSBkaXNj dXNzZWQgaW4gQ2hpY2FnbyBhbnl3YXlzLCBGV0lXLg0KDQpUaGF0IHNhaWQsIG15IGV4cGVjdGF0 aW9uIGlzIHRoYXQgdGhlcmUgYXJlIHRocmVlIHR5cGVzIG9mIG1pZGRsZWJveGVzIHRoYXQgd2Ug d2FudCB0byBhZGRyZXNzOg0KKGkpIFRob3NlIHRoYXQgd2FudCB0byBzZXBhcmF0ZSBRVUlDIGNv bm5lY3Rpb25zIGZyb20gdW53YXJyYW50ZWQgdHJhZmZpYzsNCihpaSkgVGhvc2UgdGhhdCB3YW50 IHRvIHRyYWNrIFFVSUMgY29ubmVjdGlvbiBzdGF0ZTsgYW5kDQooaWlpKSBUaG9zZSB0aGF0IHdh bnQgdG8gZmlyZXdhbGwgY2VydGFpbiBzZXJ2aWNlcyAoZWcuLCBXZWJSVEMpLiBNaWRkbGVib3hl cyBhcmUgaW50ZXJlc3RlZCBpbiBibG9ja2luZyBzZXJ2aWNlcywgbm90IHRoZSB0cmFuc3BvcnQu DQoNCihpaWkpIGlzIGJhc2ljYWxseSBzb2x2ZWQgdXNpbmcgdGhlIHNhbWUgc2lnbmFscyB0aGF0 IG1pZGRsZWJveGVzIHVzZSB0b2RheTogc2VydmVyIHBvcnQgbnVtYmVyLiBCbG9ja2luZyBVRFAg dG8gcG9ydCA0NDMgZWZmZWN0aXZlbHkgYmxvY2tzIHVzZSBvZiBRVUlDIGZvciBIVFRQUy4NCg0K Rm9yIChpKSBhbmQgKGlpKSwgaWYgbWlkZGxlYm94ZXMgYXJlIGJlaW5nIG1vZGlmaWVkIHRvIGRl dGVjdCBRVUlDLCBJIGRvbid0IHRoaW5rIHRoZXknZCBoYXZlIHRyb3VibGUgZ29pbmcgdGhyb3Vn aCB0aGUgc3RhdGUgbWFjaGluZSBhbmQgcmVtZW1iZXJpbmcgd2hlcmUgdGhlIFFVSUMgY29ubmVj dGlvbiBJRCBmYWxscy4gSSBhcHByZWNpYXRlIHlvdXIgY29uY2VybiBhYm91dCBvc3NpZmljYXRp b24gb2Ygc3BlY2lmaWMgdmVyc2lvbnMsIGJ1dCBpZiB0aGVyZSBhcmUgb3NzaWZpZWQgbWlkZGxl Ym94ZXMgdGhhdCBuZWVkIHRvIHRyYWNrIGNvbm5lY3Rpb24gc3RhdGUgKHR5cGUgKGlpaSkgYWJv dmUpLCB0aGVuIHdlJ3JlIHN0dWNrIHdpdGggdGhlIHBvc2l0aW9uIG9mIHRoZSBjb25uZWN0aW9u IElEIGFueXdheXMuDQoNClNwZWNpZnlpbmcgdGhlIHZlcnNpb24gb3Igc2VuZGluZyBhIG1hZ2lj IG51bWJlciBpbiBlYWNoIHBhY2tldCBoYXMgcXVhbnRpZmlhYmxlIG92ZXJoZWFkIGNvc3QgYnV0 IHRoZSBiZW5lZml0cyBhcmUgdW5rbm93biwgYW5kIEknZCBiZSBpbmNsaW5lZCBhZ2FpbnN0IHRo ZW0uIEZvciBpbi1uZXR3b3JrIG1lYXN1cmVtZW50cywgYXMgd2UndmUgZGlzY3Vzc2VkIHByZXZp b3VzbHksIHRoZXJlIG1heSBiZSB2YWx1ZSBpbiBzZW5kaW5nIHRoZSAibGFyZ2VzdCBvYnNlcnZl ZCIgaW4gdGhhdCBoZWFkZXIuDQoNCk9uIFR1ZSwgSmFuIDMxLCAyMDE3IGF0IDE6MTYgQU0sIEdv cnJ5IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRu LmFjLnVrPj4gd3JvdGU6DQpJIHNlZSByZWFsIG1lcml0IGluIG1vdmluZyBiZXlvbmQgKDEpIGZv ciBhbm90aGVyIHJlYXNvbiBpZiB0aGlzIGV4cG9zZXMgYXQgbGVhc3QgY29ubmVjdGlvbiBJRCwg cGFja2V0IG51bWJlciwgcGFja2V0IG51bWJlciBlY2hvIChhc3VtaW5nIG9uZSBjYW4gYWxzbyBk ZXJpdmUgKGJlZ2luL2VuZCBvZiBmbG93LCBldGMgZm9yIGEgdHJhZmZpYyBmbG93Lg0KDQpPdmVy IHRoZSB5ZWFycyBJJ3ZlIHNlZW4gdGhlIElFVEYgcHJvZHVjZSBxdWl0ZSBhIGZldyAidHJhbnNw b3J0IiBwcm90b2NvbHMsIGFuZCB3aGlsZSBlYWNoIG9mIHRoZW0gaGFzIGhhZCBkaWZmZXJlbnQg cmVxdWlyZW1lbnRzIGFuZCBhbWJpdGlvbnMsIEknZCBsaWtlIHRvIG9ic2VydmUgdGhhdCBzdWNj ZXNzZnVsIG9uZXMgb2Z0ZW4gaW5jbHVkZSBhbiBhYmlsaXR5IGZvciBuZXR3b3JrIG9wZXJhdG9y cyBhbmQgaW5kZXBlbmRlbnQgcmVzZWFyY2hlcnMgdG8gYm90aCBnYXRoZXIgcGVyLWZsb3cgdHJh ZmZpYyBtZWFzdXJlbWVudHMgYW5kIHRvIHVuZGVyc3RhbmQgcGF0aG9sb2dpZXMgb2YgaG93IHRy YWZmaWMgZmxvd3Mgc2hhcmUgY2FwYWNpdHkgYW5kIHVuZGVyc3RhbmQgd2hlcmUgcHJvYmxlbXMg ZXhpc3Qgd2l0aGluIG5ldHdvcmtzLiBEb2luZyB0aGlzIHdpdGhpbiB0aGUgbmV0d29yayByZWxp ZXMgb24gdmlzaWJpbGl0eSBvZiBhdCBsZWFzdCBmaWVsZHMgd2l0aCB2aXNpYmlsaXR5IG9mIGJh c2ljIGZsb3cgaW5mb3JtYXRpb24gaW4gdGhlIHBheWxvYWQuDQoNCkl0J3MgT0sgZnJvIG1lIHRv aGF2ZSBydWxlcyBhYm91dCB3aGV0aGVyIHBhY2tldCBudW1iZXJzIGhhdmUgdG8gbW9ub3RvbWlj YWxseSBpbmNyZWFzZSB0byBiZSB1c2VmdWwgYXQgYSByZWNlaXZlciwgd2hldGhlciByZWNlaXZl cnMgY2FuIHVzZWZ1bGx5IHVzZSByZS1yZXNlcXVlbmNlZCBwYWNrZXRzLCBvciBkYXRhIHdpdGgg Z2FwcywgZXRjLiBFdmVuIHdpdGggdGhlc2UgY29uc3RyYWludHMsIGEgc2V0IG9mIHZpc2libGUg ZmllbGRzIGNvdWxkIHN0aWxsIG9wZW4tdXAgZGF0YSBvbiB3aGV0aGVyIG15IGN1cnJlbnQgbmV0 d29yayBsaW5rIGlzIHNlZWluZyBtb3JlICJnYXBzIiwgInJlc2VxdWVuY2luZyIsICJ3aGF0ZXZl ciIgY29tcGFyZWQgdG8gYSBtZWFzdXJlbWVudCBhdCBhbm90aGVyIHRpbWUgb2YgZGF5LCBvciBh bm90aGVyIHR5cGUgb2YgbmV0d29yayBsaW5rIC0gYWxsIG9mIHdoaWNoIGNhbiBiZSBoZWxwZnVs IGluIHVuZGVyc3RhbmRpbmcgaG93IHRvIG9wZXJhdGUgbXkgbmV0d29yaywgYW5kIHdoZXRoZXIg dGhpcyB0cmFmZmljIGlzIGNvLWV4aXN0aW5nIHdpdGggb3RoZXIgdHJhbnNwb3J0IHNlcnZpY2Vz LiBBcyB3ZSBsb29rIGFoZWFkIHRvIG5ldHdvcmtzIHdpdGggZ3JlYXRlciB2YXJpYWJpbGl0eSAo NUc/KSwgbW9yZSByZW9yZGVyaW5nLCBvciB3aWRlciBtaXhlcyBvZiB0cmFmZmljIGFuZCBmb3J3 YXJkaW5nIHJ1bGVzLCB0aGlzIGJlY29tZXMgbW9yZSBpbXBvcnRhbnQsIG5vdCBsZXNzLg0KDQpH b3JyeQ0KDQoNCk9uIDMxLzAxLzIwMTcgMDA6MzUsIE1hcnRpbiBUaG9tc29uIHdyb3RlOg0KT24g MzEgSmFudWFyeSAyMDE3IGF0IDA0OjA4LCBNaXJqYSBLw7xobGV3aW5kDQo8bWlyamEua3VlaGxl d2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5j aD4+ICB3cm90ZToNCi0gcGFja2V0IG51bWJlciAoY2FuIGJlIHVzZWQgZm9yIGxvc3MgZGV0ZWN0 aW9uIG9mIGxvc3NlcyB0aGF0IG9jY3VycmVkIGJlZm9yZSB0aGUgb2JzZXJ2YXRpb24gcG9pbnQg aWYgaW5jcmVhc2VkIGxpbmVhcmx5IHdpdGhvdXQgZ2FwcyksIGFuZA0KT24gdGhpcyBwb2ludCwg ZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHNraXAgcGFja2V0IG51bWJlcnMNCnBlcmlvZGljYWxs eS4gIFRoYXQgbG9va3MgbGlrZSBsb3NzIHRvIHRoZSBvdGhlciBzaWRlIChvciB0aGUgcGF0aCks DQpidXQgZXZlbiBzcHVyaW91cyBsb3NzZXMgZG9uJ3QgaGF2ZSBhIGJpdCBpbXBhY3Qgb24gdGhp bmdzIGxpa2UNCmNvbmdlc3Rpb24gY29udHJvbCBpZiB0aGV5IGFyZSByYXJlIGVub3VnaC4NCg0K T25lIHRoaW5nIHRoYXQgd2UndmUgZGlzY3Vzc2VkIGlzIHRoZSB1c2Ugb2YgZ2FwcyB0byB2ZXJp ZnkgcGFja2V0DQpyZWNlaXB0IGFmdGVyIGEgY29ubmVjdGlvbiBtaWdyYXRpb24uICBBbiBlbmRw b2ludCB0aGF0IGRldGVjdHMgYSBtb3ZlDQpjYW4gc3RhcnQgc2tpcHBpbmcgbW9yZSBhZ2dyZXNz aXZlbHkgdG8gcHJvdGVjdCBhZ2FpbnN0IG9wdGltaXN0aWMgYWNrDQphdHRhY2tzIG9uIHRoYXQg bmV3IHBhdGguICBJIGd1ZXNzIHRoYXQgeW91IGNvdWxkIGFyZ3VlIHRoYXQgZWNob2luZyBhDQpw YWNrZXQgbnVtYmVyIGFjaGlldmVzIHRoZSBzYW1lIGVmZmVjdCBtb3JlIGVmZmljaWVudGx5LCBi dXQgd2Ugd291bGQNCm5lZWQgdG8gYXNzZXNzIHRoYXQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGJ5 dGVzIGl0IHdvdWxkIGV4cGVuZA0Kb3ZlcmFsbC4NCg0KDQo= --_000_BN6PR03MB2708A10A97706770EA8A0CB0874A0BN6PR03MB2708namp_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIChpaWkpLCBJ IGRvbuKAmXQgdGhpbmsgd2XigJlyZSB0aGF0IG9zc2lmaWVkIG9uIFVEUCB5ZXQuJm5ic3A7IEhU VFAvUVVJQyBkb2VzbuKAmXQgcmVzZXJ2ZSBhIFVEUCBwb3J0IG51bWJlci4mbmJzcDsgWW91IG9u bHkgZmluZCBvdXQgYWJvdXQgdGhlIGhvc3QvcG9ydCB0aHJvdWdoIHRoZSBBbHQtU3ZjIGFkdmVy dGlzZW1lbnQsIGFuZCB0aGF0IGNhbiBhZHZlcnRpc2UgYW55IHBvcnQgaXQgbGlrZXMuJm5ic3A7 IFRoZXJlIG1heQ0KIGJlIGEgY29udmVudGlvbiB0aGF0IHNlcnZlcnMgdXNlIDo0NDPigKYuJm5i c3A7IEJ1dCB0aGVuIGFnYWluLCBpdCBtaWdodCBiZSB3b3J0aCBhdm9pZGluZyB0aGF0IGNvbnZl bnRpb24gaWYgaXQgaGVscHMgbWluaW1pemUgb3NzaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g PGI+T24gQmVoYWxmIE9mDQo8L2I+SmFuYSBJeWVuZ2FyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIEphbnVhcnkgMzEsIDIwMTcgMTA6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEdvcnJ5IChlcmcp ICZsdDtnb3JyeUBlcmcuYWJkbi5hYy51ayZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pcmphIEvDvGhs ZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21z b25AZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogT3NzaWZpY2F0aW9uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbG9hdGhlIHRvIGluY3JlYXNlIHRoZSBR VUlDIHBhY2tldCBoZWFkZXIgc2l6ZSB0byBhdm9pZCBpbmNyZWFzaW5nbHkgYWRkaXRpb25hbCBv dmVyaGVhZC4gSSBhZ3JlZSB0aGF0ICgxKSBzZWVtcyBmdW5kYW1lbnRhbGx5IGhhcmQgdG8gZG8g d2l0aG91dCBzdWJzdGFudGlhbCBjb21wdXRhdGlvbmFsIGNvc3QgYW5kIG90aGVyIG92ZXJoZWFk LCBzbyBJJ2QgYmUgZmluZSB3aXRoIGV4cG9zaW5nIHNvbWUgdGhpbmdzLg0KIEkgdGhpbmsgdGhp cyBpcyBleHBlY3RlZCB0byBiZSBkaXNjdXNzZWQgaW4gQ2hpY2FnbyBhbnl3YXlzLCBGV0lXLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzYWlkLCBt eSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZXJlIGFyZSB0aHJlZSB0eXBlcyBvZiBtaWRkbGVib3hl cyB0aGF0IHdlIHdhbnQgdG8gYWRkcmVzczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPihpKSBUaG9zZSB0aGF0IHdhbnQgdG8gc2VwYXJhdGUgUVVJ QyBjb25uZWN0aW9ucyBmcm9tIHVud2FycmFudGVkIHRyYWZmaWM7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oaWkpIFRob3NlIHRoYXQgd2FudCB0 byB0cmFjayBRVUlDIGNvbm5lY3Rpb24gc3RhdGU7IGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGlpaSkgVGhvc2UgdGhhdCB3YW50IHRvIGZp cmV3YWxsIGNlcnRhaW4gc2VydmljZXMgKGVnLiwgV2ViUlRDKS4gTWlkZGxlYm94ZXMgYXJlIGlu dGVyZXN0ZWQgaW4gYmxvY2tpbmcgc2VydmljZXMsIG5vdCB0aGUgdHJhbnNwb3J0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oaWlpKSBpcyBi YXNpY2FsbHkgc29sdmVkIHVzaW5nIHRoZSBzYW1lIHNpZ25hbHMgdGhhdCBtaWRkbGVib3hlcyB1 c2UgdG9kYXk6IHNlcnZlciBwb3J0IG51bWJlci4gQmxvY2tpbmcgVURQIHRvIHBvcnQgNDQzIGVm ZmVjdGl2ZWx5IGJsb2NrcyB1c2Ugb2YgUVVJQyBmb3IgSFRUUFMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciAoaSkgYW5kIChpaSksIGlm IG1pZGRsZWJveGVzIGFyZSBiZWluZyBtb2RpZmllZCB0byBkZXRlY3QgUVVJQywgSSBkb24ndCB0 aGluayB0aGV5J2QgaGF2ZSB0cm91YmxlIGdvaW5nIHRocm91Z2ggdGhlIHN0YXRlIG1hY2hpbmUg YW5kIHJlbWVtYmVyaW5nIHdoZXJlIHRoZSBRVUlDIGNvbm5lY3Rpb24gSUQgZmFsbHMuIEkgYXBw cmVjaWF0ZSB5b3VyIGNvbmNlcm4gYWJvdXQgb3NzaWZpY2F0aW9uIG9mIHNwZWNpZmljDQogdmVy c2lvbnMsIGJ1dCBpZiB0aGVyZSBhcmUgb3NzaWZpZWQgbWlkZGxlYm94ZXMgdGhhdCBuZWVkIHRv IHRyYWNrIGNvbm5lY3Rpb24gc3RhdGUgKHR5cGUgKGlpaSkgYWJvdmUpLCB0aGVuIHdlJ3JlIHN0 dWNrIHdpdGggdGhlIHBvc2l0aW9uIG9mIHRoZSBjb25uZWN0aW9uIElEIGFueXdheXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWNpZnlp bmcgdGhlIHZlcnNpb24gb3Igc2VuZGluZyBhIG1hZ2ljIG51bWJlciBpbiBlYWNoIHBhY2tldCBo YXMgcXVhbnRpZmlhYmxlIG92ZXJoZWFkIGNvc3QgYnV0IHRoZSBiZW5lZml0cyBhcmUgdW5rbm93 biwgYW5kIEknZCBiZSBpbmNsaW5lZCBhZ2FpbnN0IHRoZW0uIEZvciBpbi1uZXR3b3JrIG1lYXN1 cmVtZW50cywgYXMgd2UndmUgZGlzY3Vzc2VkIHByZXZpb3VzbHksIHRoZXJlIG1heSBiZSB2YWx1 ZQ0KIGluIHNlbmRpbmcgdGhlICZxdW90O2xhcmdlc3Qgb2JzZXJ2ZWQmcXVvdDsgaW4gdGhhdCBo ZWFkZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFR1ZSwgSmFuIDMxLCAyMDE3IGF0IDE6MTYgQU0sIEdvcnJ5IEZhaXJodXJzdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIiB0YXJnZXQ9Il9ibGFuayI+Z29y cnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSByZWFsIG1lcml0IGluIG1vdmluZyBiZXlv bmQgKDEpIGZvciBhbm90aGVyIHJlYXNvbiBpZiB0aGlzIGV4cG9zZXMgYXQgbGVhc3QgY29ubmVj dGlvbiBJRCwgcGFja2V0IG51bWJlciwgcGFja2V0IG51bWJlciBlY2hvIChhc3VtaW5nIG9uZSBj YW4gYWxzbyBkZXJpdmUgKGJlZ2luL2VuZCBvZiBmbG93LCBldGMgZm9yIGEgdHJhZmZpYyBmbG93 Ljxicj4NCjxicj4NCk92ZXIgdGhlIHllYXJzIEkndmUgc2VlbiB0aGUgSUVURiBwcm9kdWNlIHF1 aXRlIGEgZmV3ICZxdW90O3RyYW5zcG9ydCZxdW90OyBwcm90b2NvbHMsIGFuZCB3aGlsZSBlYWNo IG9mIHRoZW0gaGFzIGhhZCBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIGFuZCBhbWJpdGlvbnMsIEkn ZCBsaWtlIHRvIG9ic2VydmUgdGhhdCBzdWNjZXNzZnVsIG9uZXMgb2Z0ZW4gaW5jbHVkZSBhbiBh YmlsaXR5IGZvciBuZXR3b3JrIG9wZXJhdG9ycyBhbmQgaW5kZXBlbmRlbnQgcmVzZWFyY2hlcnMN CiB0byBib3RoIGdhdGhlciBwZXItZmxvdyB0cmFmZmljIG1lYXN1cmVtZW50cyBhbmQgdG8gdW5k ZXJzdGFuZCBwYXRob2xvZ2llcyBvZiBob3cgdHJhZmZpYyBmbG93cyBzaGFyZSBjYXBhY2l0eSBh bmQgdW5kZXJzdGFuZCB3aGVyZSBwcm9ibGVtcyBleGlzdCB3aXRoaW4gbmV0d29ya3MuIERvaW5n IHRoaXMgd2l0aGluIHRoZSBuZXR3b3JrIHJlbGllcyBvbiB2aXNpYmlsaXR5IG9mIGF0IGxlYXN0 IGZpZWxkcyB3aXRoIHZpc2liaWxpdHkgb2YgYmFzaWMNCiBmbG93IGluZm9ybWF0aW9uIGluIHRo ZSBwYXlsb2FkLjxicj4NCjxicj4NCkl0J3MgT0sgZnJvIG1lIHRvaGF2ZSBydWxlcyBhYm91dCB3 aGV0aGVyIHBhY2tldCBudW1iZXJzIGhhdmUgdG8gbW9ub3RvbWljYWxseSBpbmNyZWFzZSB0byBi ZSB1c2VmdWwgYXQgYSByZWNlaXZlciwgd2hldGhlciByZWNlaXZlcnMgY2FuIHVzZWZ1bGx5IHVz ZSByZS1yZXNlcXVlbmNlZCBwYWNrZXRzLCBvciBkYXRhIHdpdGggZ2FwcywgZXRjLiBFdmVuIHdp dGggdGhlc2UgY29uc3RyYWludHMsIGEgc2V0IG9mIHZpc2libGUgZmllbGRzIGNvdWxkDQogc3Rp bGwgb3Blbi11cCBkYXRhIG9uIHdoZXRoZXIgbXkgY3VycmVudCBuZXR3b3JrIGxpbmsgaXMgc2Vl aW5nIG1vcmUgJnF1b3Q7Z2FwcyZxdW90OywgJnF1b3Q7cmVzZXF1ZW5jaW5nJnF1b3Q7LCAmcXVv dDt3aGF0ZXZlciZxdW90OyBjb21wYXJlZCB0byBhIG1lYXN1cmVtZW50IGF0IGFub3RoZXIgdGlt ZSBvZiBkYXksIG9yIGFub3RoZXIgdHlwZSBvZiBuZXR3b3JrIGxpbmsgLSBhbGwgb2Ygd2hpY2gg Y2FuIGJlIGhlbHBmdWwgaW4gdW5kZXJzdGFuZGluZyBob3cgdG8gb3BlcmF0ZSBteSBuZXR3b3Jr LA0KIGFuZCB3aGV0aGVyIHRoaXMgdHJhZmZpYyBpcyBjby1leGlzdGluZyB3aXRoIG90aGVyIHRy YW5zcG9ydCBzZXJ2aWNlcy4gQXMgd2UgbG9vayBhaGVhZCB0byBuZXR3b3JrcyB3aXRoIGdyZWF0 ZXIgdmFyaWFiaWxpdHkgKDVHPyksIG1vcmUgcmVvcmRlcmluZywgb3Igd2lkZXIgbWl4ZXMgb2Yg dHJhZmZpYyBhbmQgZm9yd2FyZGluZyBydWxlcywgdGhpcyBiZWNvbWVzIG1vcmUgaW1wb3J0YW50 LCBub3QgbGVzcy48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+R29ycnk8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiAzMS8wMS8yMDE3IDAw OjM1LCBNYXJ0aW4gVGhvbXNvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzMSBKYW51YXJ5IDIwMTcgYXQgMDQ6MDgsIE1pcmphIEvD vGhsZXdpbmQ8YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVl LmV0aHouY2giIHRhcmdldD0iX2JsYW5rIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNo PC9hPiZndDsmbmJzcDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBwYWNrZXQgbnVtYmVyIChjYW4gYmUgdXNlZCBmb3IgbG9zcyBkZXRl Y3Rpb24gb2YgbG9zc2VzIHRoYXQgb2NjdXJyZWQgYmVmb3JlIHRoZSBvYnNlcnZhdGlvbiBwb2lu dCBpZiBpbmNyZWFzZWQgbGluZWFybHkgd2l0aG91dCBnYXBzKSwgYW5kPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGlzIHBvaW50LCBleGlz dGluZyBpbXBsZW1lbnRhdGlvbnMgc2tpcCBwYWNrZXQgbnVtYmVyczxicj4NCnBlcmlvZGljYWxs eS4mbmJzcDsgVGhhdCBsb29rcyBsaWtlIGxvc3MgdG8gdGhlIG90aGVyIHNpZGUgKG9yIHRoZSBw YXRoKSw8YnI+DQpidXQgZXZlbiBzcHVyaW91cyBsb3NzZXMgZG9uJ3QgaGF2ZSBhIGJpdCBpbXBh Y3Qgb24gdGhpbmdzIGxpa2U8YnI+DQpjb25nZXN0aW9uIGNvbnRyb2wgaWYgdGhleSBhcmUgcmFy ZSBlbm91Z2guPGJyPg0KPGJyPg0KT25lIHRoaW5nIHRoYXQgd2UndmUgZGlzY3Vzc2VkIGlzIHRo ZSB1c2Ugb2YgZ2FwcyB0byB2ZXJpZnkgcGFja2V0PGJyPg0KcmVjZWlwdCBhZnRlciBhIGNvbm5l Y3Rpb24gbWlncmF0aW9uLiZuYnNwOyBBbiBlbmRwb2ludCB0aGF0IGRldGVjdHMgYSBtb3ZlPGJy Pg0KY2FuIHN0YXJ0IHNraXBwaW5nIG1vcmUgYWdncmVzc2l2ZWx5IHRvIHByb3RlY3QgYWdhaW5z dCBvcHRpbWlzdGljIGFjazxicj4NCmF0dGFja3Mgb24gdGhhdCBuZXcgcGF0aC4mbmJzcDsgSSBn dWVzcyB0aGF0IHlvdSBjb3VsZCBhcmd1ZSB0aGF0IGVjaG9pbmcgYTxicj4NCnBhY2tldCBudW1i ZXIgYWNoaWV2ZXMgdGhlIHNhbWUgZWZmZWN0IG1vcmUgZWZmaWNpZW50bHksIGJ1dCB3ZSB3b3Vs ZDxicj4NCm5lZWQgdG8gYXNzZXNzIHRoYXQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGJ5dGVzIGl0 IHdvdWxkIGV4cGVuZDxicj4NCm92ZXJhbGwuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB2708A10A97706770EA8A0CB0874A0BN6PR03MB2708namp_-- From nobody Tue Jan 31 13:28: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 BF276129AE0 for ; Tue, 31 Jan 2017 13:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WavdHXjmiTQ9 for ; Tue, 31 Jan 2017 13:28:28 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0114.outbound.protection.outlook.com [104.47.37.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02993129ADC for ; Tue, 31 Jan 2017 13:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=URyyV/wgRO07g2eJ/xLiBev+zyCVX1bRRh7625OphOU=; b=fx+Q8+A90zYXHocZ0/cDIGnROh2IJlhtRJ9tk5b4UJQGKJjng7BxSYdXJbYg8u9km/aC0iJeULeuI+cGW2tQrMdAYpN6wyROsWL4vkW8pKP+jMZXMl8v2cQG4bgtXCkj6TmHRn/VBHig9nwQ5oZrhX2u7LIQlZNFY10WIHB6SVc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 31 Jan 2017 21:28:25 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0860.026; Tue, 31 Jan 2017 21:28:25 +0000 From: Mike Bishop To: IETF QUIC WG Subject: Consensus notification: QUIC advertisement description (#87) Thread-Topic: Consensus notification: QUIC advertisement description (#87) Thread-Index: AdJ8BhTgGXuJa5V8TtOKm9140f600Q== Date: Tue, 31 Jan 2017 21:28:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:8::51f] x-ms-office365-filtering-correlation-id: 2db92148-9c7a-4283-8b00-08d44a201729 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401079); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:6k3mkM9SFNDkyll1RWXM2huCjZtqDdhPWCHa63IfAAOpOOtqkenOkApEuI1R+4NdiO7obDbOq72BxMGHnuApvBdaD1Ny+j5FvqHLS7efreqMgoxIq+l94LWQqzsxByaiCH9uVB+ymIKBiY7ktDUBmOoS7onyjV3QP/30dQ3D/SKLu4j1mdEck8FU8pcdtjp4bf8Ni9RZBJRizpr64gPn7QScCn6hcsUAlJOw0TMIm8mhXDJ6GzipVY7N5PXqIje8T6eQn4I26GWrzpjU5nDfG5gSOh6mgxUYjPw9D25BfS5QUPT6mSkyhfd5BYEEngXR3negCirv5p6eNhuAnWGY1fLMrAKNfNSUlx/D5/SrQ9Puovz7EgwCULKoj2r/uwfuCfBYsK+USwuD5OzUFVY3CToHUqSGA0He8o1V6ZQ7rMTgNZ8ZmT7GfwI1YTpazaUNGmXw1wvBp6905KdvY+ehlCXHPJZaHgESuaQPgY0b2Wnkd0cOjitMAd2yxiKRopI0SS4B8CceKLbl4+daCA9a2792Crap3ExEXGs9wTgPe4O3SWT1gZZco/qrgvoWFqNO x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6042181)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(122556002)(110136003)(86362001)(81166006)(8936002)(86612001)(38730400001)(81156014)(77096006)(10090500001)(6306002)(92566002)(107886002)(25786008)(9686003)(54896002)(7696004)(97736004)(10290500002)(6436002)(606005)(8676002)(5005710100001)(6916009)(450100001)(2900100001)(99286003)(55016002)(6506006)(189998001)(53936002)(33656002)(7736002)(105586002)(5660300001)(236005)(7906003)(74316002)(54356999)(106356001)(3280700002)(3660700001)(68736007)(102836003)(101416001)(6116002)(790700001)(8990500004)(2906002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708F7A25ABF470C324F8212874A0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 21:28:25.2428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:28:30 -0000 --_000_BN6PR03MB2708F7A25ABF470C324F8212874A0BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This issue tracks the defi= nition of HTTP/QUIC's ALPN identifier and the version-negotiation hint to A= lt-Svc. Text was originally proposed in PR #90 and incorporated in draft -= 01. During the interim in Tokyo, we agreed to use quic=3D instead of v=3D, sinc= e the format has changed from Google's existing use, and because v=3D is a = bit generic. This change, along with some editorial feedback, is in PR #23= 5. I'd like to get more eyes on it, and if there's still consensus, merge the = change and close the issue. --_000_BN6PR03MB2708F7A25ABF470C324F8212874A0BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This issue tracks the definition of HTTP/QUIC’s ALPN iden= tifier and the version-negotiation hint to Alt-Svc.  Text was original= ly proposed in PR #90 and incorporated in draft -01.

 

During the interim in Tokyo, we agreed to use quic= =3D instead of v=3D, since the format has changed from Google’s exist= ing use, and because v=3D is a bit generic.  This change, along with s= ome editorial feedback, is in PR #235.

 

I’d like to get more eyes on it, and if there&= #8217;s still consensus, merge the change and close the issue.

--_000_BN6PR03MB2708F7A25ABF470C324F8212874A0BN6PR03MB2708namp_-- From nobody Tue Jan 31 15:07:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C837129644 for ; Tue, 31 Jan 2017 15:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 VV9dPV1cqVu7 for ; Tue, 31 Jan 2017 15:07:03 -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 79998129631 for ; Tue, 31 Jan 2017 15:07:03 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id c7so5488611itd.1 for ; Tue, 31 Jan 2017 15:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qNL4gWic/pTHaObsy1k1xkNrpVe0+KAfTKzn/rt7/ek=; b=PyKvgRDOQbmN3AGRIkuzF4Fx6JDOdoK3eIn2avNSG5/HzoP0lHKnBpu6CXj4VoLJaM l2jjrxxlJC3H+icZbR/2XcWzYpcNylIlaaFv4m25e1h0eqlsVANgLifjN+kbMb98jyw0 sc5Qubhm5I0bmROQEi5D3HzWIMccUOqDDRdnnbFTxoDTj9mMNvtcWI3NnZDEFoUythyO pD4OufpE+7Tlm94nTqGmA+Gsl7FkUwTTdHMyeGHBDQ7v53GRgn4+Rlhrlr0YF7c+mCQd nCC1YzMD3TNCH+sZ2J2c5HIJgaHrsRS9YiI/QZ+D7igpmKdUueomPSpKR62Ai6lqtoqe 19dg== 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=qNL4gWic/pTHaObsy1k1xkNrpVe0+KAfTKzn/rt7/ek=; b=A4Af+Zw3dm61gAUDl04ue6JgxMVZG8KpUvi0Rj133eH7Cw4WCWt/g7Zv7kS2cW6VXV wdsPKQ9V4n7D54MTywt+GkyA+k0wBxmBjnvEYBKNfItgpCAAzUMXaB2QV9vuf//YQHzC X20kDMOjmo1++WHTgL7tr1LfFRftN+LXGulvy8uWQ1X9JjuHGxjZcYg3W3fmUG07S+f7 hD6fY2O1N4wXDaKPqKOHuVaYgUwpJhFtCXi5T7VDwuXhzc9+EGHBdVVzb333JUMaEAhF +hLCiu8DnSfohhtR63+O7rZCK9LThXYA//b2aQsA/7tdjQAL1EmthGU+raBa9yWgiIKa J/4A== X-Gm-Message-State: AIkVDXLyafF4TLvPEygvIpIss9T/F1p1czkRZPOX1GwafA/WWrXJ9AeliconNScAqLT1jaCkoyqmuSk8onqys2nb X-Received: by 10.36.7.196 with SMTP id f187mr22433111itf.65.1485904022667; Tue, 31 Jan 2017 15:07:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.112 with HTTP; Tue, 31 Jan 2017 15:06:42 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Tue, 31 Jan 2017 15:06:42 -0800 Message-ID: Subject: Re: Splitting QPACK To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1143e27871670905476bfdb1 Archived-At: Cc: IETF QUIC WG , Ryan Hamilton , Kazuho Oku X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 31 Jan 2017 23:07:05 -0000 --001a1143e27871670905476bfdb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2017 at 12:50 PM, Mike Bishop wrote: > Yes, if the encoder was both determined never to HOLB and did it that > way. I think more realistic might be to say that writing something small > to the headers stream and writing the full header set to the request stre= am > at the same time, they=E2=80=99re very likely to wind up in the same pack= et. > Ok I get it now. For the header that causes a table insert, it would be ill-advised to use a hpack literal on the headers stream. There's no point guarding HoL blocking among things that that will end up in the same packet anyway. > Depending on the integration you have with your transport stack, there > might even be a way for an implementation to guarantee that, but that=E2= =80=99s > beyond the scope of a protocol document. > > > > *From:* Charles 'Buck' Krasic [mailto:ckrasic@google.com] > *Sent:* Tuesday, January 31, 2017 9:53 AM > *To:* Kazuho Oku > *Cc:* Mike Bishop ; IETF QUIC WG < > quic@ietf.org>; Ryan Hamilton > *Subject:* Re: Splitting QPACK > > > > One more thought/question about a dedicated stream for updates. Would > it penalize the compression of HoL avoiding further, in the sense that wh= at > would be an incremental update today would be an update on the control > stream, along with a literal on the data stream? I.e. minimum two litera= ls > for most entries added to the table? > > > > On Tue, Jan 31, 2017 at 9:46 AM, Charles 'Buck' Krasic > wrote: > > > > > > On Mon, Jan 30, 2017 at 5:52 PM, Kazuho Oku wrote: > > 2017-01-30 12:45 GMT+09:00 Mike Bishop : > > Yes, it would mean bringing back the DATA frame from HTTP/2. Given tha= t > we > > already have intra-stream framing (on one stream of two), that didn=E2= =80=99t > seem > > like a big loss to me. However, I can believe that there are performan= ce > > efficiencies to be gained from being able to dispense with framing once > you > > get to the body. > > My two cents go to using single stream for both headers and body, > since I'd be worried of the maximum amount of memory that would be > consumed by the per-stream receive windows. > > If we could send headers and body on a single stream then it would > mean that the maximum number of streams that an endpoint becomes half > when compared to current approach. That would in turn mean that the > maximum amount of memory that needs to be allocated for the receive > windows becomes half, or that the size of per-stream receive windows > can be doubled while keeping the maximum same to the current draft. > > > > When memory is a concern, I think an implementation should consider > auto-tuning the receive window sizes. The Google QUIC code does this. > Under such a regime, the total amount of memory used by receive buffer= s > has more to do with aggregate BDP than number of streams. > > > > > > > > > From: Ryan Hamilton [mailto:rch@google.com] > > Sent: Sunday, January 29, 2017 7:12 PM > > To: Mike Bishop > > Cc: IETF QUIC WG > > Subject: Re: Splitting QPACK > > > > > > > > > > > > On Sun, Jan 29, 2017 at 6:46 PM, Mike Bishop < > Michael.Bishop@microsoft.com> > > wrote: > > > > Also, if we go this way, the remaining reasons to separate headers and > data > > seem to have disappeared, and we might be able to get down to one strea= m > per > > request. > > > > > > > > We'd still need some mechanism, within a stream, to delimit headers dat= a > > from body data, right? Using two QUIC streams solves this problem > nicely. I > > don't love adding more intra-stream framing, if we can avoid it. > > > > > > > -- > Kazuho Oku > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 <(408)%20412-1141> > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 <(408)%20412-1141> --001a1143e27871670905476bfdb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 31, 2017 at 12:50 PM, Mike Bishop <Michael.Bish= op@microsoft.com> wrote:

Yes, if the encoder was both determined never to HOL= B and did it that way.=C2=A0 I think more realistic might be to say that wr= iting something small to the headers stream and writing the full header set= to the request stream at the same time, they=E2=80=99re very likely to wind up in the same packet.=C2=A0


Ok I get it now.=C2=A0 For the head= er that causes a table insert, it would be ill-advised to use a hpack liter= al on the headers stream. =C2=A0 There's no point guarding HoL blocking= among things that that will end up in the same packet anyway.
= =C2=A0

Depending on the integration you h= ave with your transport stack, there might even be a way for an implementat= ion to guarantee that, but that=E2=80=99s beyond the scope of a protocol do= cument.



=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

From: Charles 'Buck' Krasic [mailto:<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com]
Sent: Tuesday, January 31, 2017 9:53 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG &= lt;quic@ietf.org>= ; Ryan Hamilton <rch= @google.com>
Subject: Re: Splitting QPACK

=C2=A0

One more thought/question about a dedicated stream f= or updates. =C2=A0 =C2=A0Would it penalize the compression of HoL avoiding = further, in the sense that what would be an incremental update today would = be an update on the control stream, along with a literal on the data stream?=C2=A0 I.e. minimum two literals for most ent= ries added to the table?

=C2=A0

On Tue, Jan 31, 2017 at 9:46 AM, Charles 'Buck&#= 39; Krasic <ckra= sic@google.com> wrote:

=C2=A0

=C2=A0

On Mon, Jan 30, 2017 at 5:52 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:

2017-01-30 12:45 GMT+09:00 Mike Bishop <Michael.Bishop@m= icrosoft.com>:
> Yes, it would mean bringing back the DATA frame from HTTP/2.=C2=A0 Giv= en that we
> already have intra-stream framing (on one stream of two), that didn=E2= =80=99t seem
> like a big loss to me.=C2=A0 However, I can believe that there are per= formance
> efficiencies to be gained from being able to dispense with framing onc= e you
> get to the body.

My two cents go to using single stream for both headers and body,
since I'd be worried of the maximum amount of memory that would be
consumed by the per-stream receive windows.

If we could send headers and body on a single stream then it would
mean that the maximum number of streams that an endpoint becomes half
when compared to current approach. That would in turn mean that the
maximum amount of memory that needs to be allocated for the receive
windows becomes half, or that the size of per-stream receive windows
can be doubled while keeping the maximum same to the current draft.<= u>

=C2=A0

When memory is a concern, I think an implementation = should consider auto-tuning the receive window sizes. =C2=A0 =C2=A0The Goog= le QUIC code does this. =C2=A0 =C2=A0 =C2=A0Under such a regime, the total = amount of memory used by receive buffers has more to do with aggregate BDP than number of streams.

=C2=A0

--
Kazuho Oku



=

=C2=A0

-- <= /p>



=C2=A0

--

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




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

--001a1143e27871670905476bfdb1-- From nobody Tue Jan 31 15:08: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 2C1F612A02B for ; Tue, 31 Jan 2017 15:08:08 -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 g8I--xs6AljV for ; Tue, 31 Jan 2017 15:08:07 -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 1E097129BFE for ; Tue, 31 Jan 2017 15:08:07 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id k15so249614187qtg.3 for ; Tue, 31 Jan 2017 15:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yaanf0vwOx4ncvoWrbwZF2JfegHQHfFDhZK8/0BrPpE=; b=hATUGnBD5Hxl1jq0Gf+OYKHtiRm6tR1jyw1+G2tHdaMFoxi79C5azfvzdfLA5tPNn4 JqQDQjharmQqTHeEksye9uUWL7f0S+2fxzSsaqcR4jXIu6mDm8yk2gKIGAsNvIp2GrUn cCXBv2Uu1Sp91KOrh9PhxdlVk3mGIzHtkvrteo1YuijBTzN0iUe4m+BI33H/Up1hdulU 9gq+N0DBrpDNtn8eYxToAJtAn96OI+SIOYblCF2wfjUhaDHY3tZXJaZfnaMh120iYDuM ZPtHOs+x7Kk8fdkoFW8ZPJLpPANlYx2tww3I990Fvu3PVApxx9BkSQr12+bl58Y032Rd whfQ== 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=Yaanf0vwOx4ncvoWrbwZF2JfegHQHfFDhZK8/0BrPpE=; b=aJoh7HTZdsbcLRAgkCLZvoggO0hbiL0Lyr2I1OkURi7QrqCoET/fFTonrewlCUmGwA GVNZQIK5kvr4a0RFqpnd1AniWDDEDo7Vwv7OErYTUKCJ9uUCBnVmXUeaHy9Tbr/eQKCR gq6nCba4C/tQaEDs9KYnWvBGXlgXE0Cw3+r6A4j7jOVmO/flpC/uQvwyV5qHFFzDseA6 fuiNoQyNu+E3+vGZsX2eR13mQD8NigS1m09qUqiaShw8S5YA1ogppaRoahVTLJHr564T 9VobXmfaD09xEvTazkA0ykJzWHVzk+vm5utyf4s6feoUa4NP5PEy82bfQ7RuVvLCloCq W9gA== X-Gm-Message-State: AIkVDXLmp4Ma1FPcyIonIdK31xMNy/x18PsDleSLXiLPoHmGEDHAXXkedSlXj9bOnqS7z65fAdyzDgbAqfN/Kg== X-Received: by 10.200.49.249 with SMTP id i54mr30219943qte.3.1485904086265; Tue, 31 Jan 2017 15:08:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 31 Jan 2017 15:08:05 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 1 Feb 2017 10:08:05 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:08:08 -0000 On 1 February 2017 at 03:27, Watson Ladd wrote: > I don't believe the finished message is necessary for ensuring > manipulation of the client hello message is detected. Nor do I. That's not the same as saying that it's perfectly safe to ignore it. From nobody Tue Jan 31 15:23:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739FC129C4B for ; Tue, 31 Jan 2017 15:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtPukSMQaYNr for ; Tue, 31 Jan 2017 15:23:06 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A1B129C48 for ; Tue, 31 Jan 2017 15:23:05 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id u25so181470950qki.2 for ; Tue, 31 Jan 2017 15:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zFTnAjJCsXPcmsiC+O+mmszOF210LD9CB61JTLRhans=; b=VCYUaXh1qwjissDddeHk5JnArEzhEbQ02BLgjD1QNo40sVggx1h2Rahk03InkBY6q1 hSuGitcCyLM7BHu2mujAjLMZsMO7IEe8+zdDBHY7CKLYL/K2ZxetFq91FXhEhvC8RGxb 62ySpHbSkUMl8nDrGPQUljoPDRvRIT7uJQl0JKGrmPoG7D9a+pvF5K2quA0ZgCB4cHxn 3SSn6dDurPrVup0Us6yyNBvakPrLtRMilbMxAuuqTbDfxt8j2/DHb+9+Y0JOEyb6IW71 hJk4bI2aWr6bTrd7QQo1kQDenIXUUqFmUXHw52GCIOaaYarx8pfkg7sDOP4xC986gKIN HB8A== 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=zFTnAjJCsXPcmsiC+O+mmszOF210LD9CB61JTLRhans=; b=iLAr4fHogh5KF1LHnosY7w5WziqlnM9VklzNv3mwoR6XtAdFsaD9PqVY2R0aIOhu1q BOi5Zc0TuktC/GxMMBSfaAsgmA+cpBKxGjXuvO6giiDdgBktvFCWh0w0kh7JleyZ3P2C 0sHJqK7rNSoIFrCaeOqM2DnyOQSEDg8PrKfvANNP0/uz6pvaec9fN7Js6sYFlDS5uuB3 QGKSPwjdxFCpA78Yw+tCev3NBU06kfCAUqZsCmMmuiIpgFHVNnnT44c6Vy2srZKGgNvn K57e/HXkFc1BbbGUgePeBKnnLYQJ+JpbO7YHDx3Hxhemf5Npz76LK8odclEYDHKtPKzz wI7A== X-Gm-Message-State: AIkVDXJIbR7XcrrdGEmec8J5oBC2mOY+7Q+XQq2Jv0F9uh+CWOdcdmDgQxpgIjOx0AN5bn74GUeEOhqSCGpx+g== X-Received: by 10.55.185.131 with SMTP id j125mr22751112qkf.115.1485904984828; Tue, 31 Jan 2017 15:23:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 31 Jan 2017 15:23:04 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 1 Feb 2017 10:23:04 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Watson Ladd , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:23:07 -0000 The security analyses of TLS assume receipt and verification of the Finished message. It's an obvious intuition that keys depend on the content of the message, therefore tampering would be easily detected. That said, we've learned that intuition is often wrong in this space, sometimes disastrously. We don't have an analysis of TLS that ignores the client Finished message. So unless and until we do, I don't want to write down anything that isn't known to be safe. I know that this sucks in subtle ways, particularly in the way that Ian observed with respect to acknowledgments. Because we require that the Finished is acknowledged with protected keys, we lose the ability to generate acknowledgments for them. I see three possible approaches: 1. As I originally suggested, suck it up and don't let the server send. 2. Don't protect the Finished (it's protected with TLS handshake keys anyway). That would allow for acknowledgment in the clear. That requires a tweak to the way that keys are shared, but it's a fairly simple tweak. The major downside is that we now have an extra packet to send, because you can't collapse the Finished message with other things (like requests). 3. In the hackiest possible way, generate a redundant ACK for the ClientHello in the clear. If that could trigger retransmission of the first encrypted packet(s), then we'd be OK. (Sorry, I haven't internalized the loss recovery stuff, so I'm not sure if this even works, we could be back into RTO space here.) Maybe option 2 is more appealing than appalling. On 1 February 2017 at 04:17, Jana Iyengar wrote: > Since the keys cannot be the same if the ClientHello were to be modified, > what is the risk we are talking about here? I don't know about the crypto > analyses of the TLS handshake, so some insight here would be helpful. But I > agree that having the server process 1-RTT data would help with loss > detection. If there's no real security implication, I'd be in favor of > letting the server process this data. > > On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd wrote: >> >> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson >> wrote: >> > In PR #39, there is a choice: >> > >> > https://github.com/quicwg/base-drafts/pull/39 >> > >> > If a server receives 1-RTT-protected packets before it receives the >> > client Finished message, it could use them. It has the keys. >> > >> > Obviously, if the server depends on certificate-based client >> > authentication it will wait. But that's still a relatively rare >> > occurrence. >> > >> > However, using 1-RTT data before verifying the Finished message could >> > leave the server more vulnerable to an attack where the ClientHello is >> > modified by an attacker. This is something that TLS 1.3 protects >> > against, but only indirectly. The traffic keys are dependent on the >> > content of the ClientHello and so it is likely that modifications of >> > the ClientHello would result in being unable to communicate. But this >> > isn't a strong assertion. The various forms of analysis of the TLS >> > 1.3 handshake have all (I think) assumed that verification of the >> > Finished message is what provides integrity for the handshake. >> >> I don't believe the finished message is necessary for ensuring >> manipulation of the client hello message is detected. >> > >> > In #39, I opted to forbid use of the client 1-RTT data until the >> > handshake completes. I'd like to confirm that this is acceptable. >> > >> > In addition to confirming this, I'd like input on what level of >> > justification is necessary for this in the document. If we believe >> > that this is the right decision, do we need to do anything to prevent >> > someone from pulling out a false start hack because they disagree with >> > this analysis? >> > >> >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> > From nobody Tue Jan 31 15:29: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 0C97B12A04E for ; Tue, 31 Jan 2017 15:29:02 -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 lWf8q843A4tf for ; Tue, 31 Jan 2017 15:29:00 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 A32B212A04D for ; Tue, 31 Jan 2017 15:29:00 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id v23so249209031qtb.0 for ; Tue, 31 Jan 2017 15:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w1ywF7z3SGmTj62pDtxb1FG+Cgkq0PPnynUFwqKJ2sc=; b=qTNMyc0c6Qs/Ht+7zwrjokitXZCvmRBvXjv37VLoSg9XyqDMwS35oaavIz34fX1nXx 6w6BsYz8c7pIJcCGhTrc4+d03IK6mDAlWDmmTj0RqdK4/TV6qu5C4XT2HiGG9/oXZvID ypnVpo7IdOzOzlGtSDymx2cDnDY2C4JRtszT85onWT8bBw4tLuJLiwH62MrgeiDZ4umx iDI2IEtlb6HC2fTYuZb3KgWktUDfUv+EO9mf3W1RlMwdqjKOOpa/24AdApJVnivF9RR/ yt2HdCHKDY0QYUpYDEAWH2DGkoQ39f6G+kklL53xC9it2kZgEruEPQDAXzkSmoZXWW02 oxSg== 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=w1ywF7z3SGmTj62pDtxb1FG+Cgkq0PPnynUFwqKJ2sc=; b=ByvT4K8FQal4v9ctgxstSi25tpJf3Zx16xJQxhm+jKQCCxPFGLpnfBBvAcBhgy9p74 2Y8YKx2pLMFdicHTvqTmJFoD7LBujNtv4WDssfA2QHShqDCC2YCQ24GEtAIrN7yVyK0F diHeaG51o0Kqm+t4udH1QoUY2SSDYETz7U2mHzqgheJzJQrw2ntRmbX4EAVKFnTx6Bin +9FysL5DQm2KWfcF9Egk0lcLw6sC5ugH8XdSRb9UBxG3kwpZ9Bf6k4/IkkHKFE6D2Chv V0popJh5Almxt61ECQMA2dEJQ0qYWHB/W7zh07zmPooSPA3fxvVoTeQh7JTrCpZmxzF6 Qoiw== X-Gm-Message-State: AIkVDXLcmA9H2bwXOYLlbNgJsb4aTzC+ljdThkIsZddGIJmbJbTJqwFhpc2zJMdEQBsrsCRX1syFbXQVKZ0/sA== X-Received: by 10.200.39.200 with SMTP id x8mr27801617qtx.159.1485905339797; Tue, 31 Jan 2017 15:28:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 31 Jan 2017 15:28:59 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 1 Feb 2017 10:28:59 +1100 Message-ID: Subject: Re: Splitting QPACK To: "Charles 'Buck' Krasic" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Kazuho Oku , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:29:02 -0000 On 1 February 2017 at 10:06, Charles 'Buck' Krasic wrote: > Ok I get it now. For the header that causes a table insert, it would be > ill-advised to use a hpack literal on the headers stream. There's no point > guarding HoL blocking among things that that will end up in the same packet > anyway. The hazard is where you have multiple concurrent uses in short order. If packetization causes the insert and the reference to appear in different packets, you have a HOLB exposure. As Mike observes, the odds of having a reference that causes an insert split between two packets is low. Well, depending on how you construct packets. You can minimize this by generating interleaved STREAM frames, but that has a bunch of overhead associated with it. It all depends on how much you want to spend to avoid stalling in the case of packet loss. I can imagine using different strategies based on observed packet loss, but then I can also imagine flying cars and we all know how common those are. From nobody Tue Jan 31 15:36:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF712963D for ; Tue, 31 Jan 2017 15:36:41 -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 cyCACx-LrPgl for ; Tue, 31 Jan 2017 15:36:39 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 B63A1129660 for ; Tue, 31 Jan 2017 15:36:38 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id v77so12307435wmv.0 for ; Tue, 31 Jan 2017 15:36:38 -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=1jOlixvg31b1yTi6l+oYe9vRX+NinyKjs+8C5HN3en4=; b=JOJPv09JD4tTSUXGR1a2zYOq7OTAyBJ8QtqbyiybvDT4c/ndM0x2eBYjBjEcricpkj IuzbRwy8gxDhV6DkcE8E3QQvlKY1EvDvf7PBSj6yOA+IJp4XHlw8Yy8p+v6C4nQB7+Xw mBikcjy5xyDzfzEFqRCR/6hGMBgN4k01mBfeYzK4ZE0ewVcKcD8UAaNGhE/TDEVmPtTS DhvysmUI51eptNRfYBLDwhiBwCKhhPF4CsiJDPgWrouBKNBsc7/BNEOiIofcAs/vlYlR OtXtV6qXoHkLOvJTHQtPuf7pdS2cAebG+QwxYoznUe/fqi1W95AnT4fJgVFrzwxa26AO yNdA== 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=1jOlixvg31b1yTi6l+oYe9vRX+NinyKjs+8C5HN3en4=; b=AdohSa4I/JhVEZTze8xNw1mIUwgPkkQlyTOqY50Ti7Jhj5QMGgUIzHCLHjzOfKBBSL jp3u3sKG9aI9leSfP5lR/zHWOobDgPWceVZLQ9mPHIth/qUc6IyoxoZSRJb5U8uXlqbL bpOU6RTlMvWf3NaRjkryhWYNFoA4IdtdSTdTborwCM9Qsls4D738Sr6EtC2vLIacDpGk YPvmYb60lY4WMHb0VL9kniVN2GMIth454lUnhE42cwCcGptqGAlYnAo5c1E4pfoFqMJl nD7192x+9T6CRClkaxkGT16X9ezt4b6QkfSDMrGmggYXNpqsjjUGR7wGEzuAB1l8LUnJ W0Vg== X-Gm-Message-State: AIkVDXKdRC1bmF6/thU4njkYTmKWZZZyIwMLkx8kbgY/3GWfZtq0przc//tg1zfZ7pozGrv30TL+g3hZk33EJA== X-Received: by 10.28.236.79 with SMTP id k76mr19908500wmh.79.1485905797178; Tue, 31 Jan 2017 15:36:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.130 with HTTP; Tue, 31 Jan 2017 15:36:36 -0800 (PST) Received: by 10.223.164.130 with HTTP; Tue, 31 Jan 2017 15:36:36 -0800 (PST) In-Reply-To: References: From: Watson Ladd Date: Tue, 31 Jan 2017 15:36:36 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114734ae35ed1005476c6736 Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:36:41 -0000 --001a114734ae35ed1005476c6736 Content-Type: text/plain; charset=UTF-8 On Jan 31, 2017 3:23 PM, "Martin Thomson" wrote: The security analyses of TLS assume receipt and verification of the Finished message. It's an obvious intuition that keys depend on the content of the message, therefore tampering would be easily detected. I think someone who is more experienced/familiar with the analysis should chime in. My understanding is that the ROM quickly gives high probability of the keys being different and hence the MAC failing, and the Finished message is there to give an explicit confirmation property. That said, we've learned that intuition is often wrong in this space, sometimes disastrously. We don't have an analysis of TLS that ignores the client Finished message. So unless and until we do, I don't want to write down anything that isn't known to be safe. I know that this sucks in subtle ways, particularly in the way that Ian observed with respect to acknowledgments. Because we require that the Finished is acknowledged with protected keys, we lose the ability to generate acknowledgments for them. I see three possible approaches: 1. As I originally suggested, suck it up and don't let the server send. 2. Don't protect the Finished (it's protected with TLS handshake keys anyway). That would allow for acknowledgment in the clear. That requires a tweak to the way that keys are shared, but it's a fairly simple tweak. The major downside is that we now have an extra packet to send, because you can't collapse the Finished message with other things (like requests). 3. In the hackiest possible way, generate a redundant ACK for the ClientHello in the clear. If that could trigger retransmission of the first encrypted packet(s), then we'd be OK. (Sorry, I haven't internalized the loss recovery stuff, so I'm not sure if this even works, we could be back into RTO space here.) Maybe option 2 is more appealing than appalling. On 1 February 2017 at 04:17, Jana Iyengar wrote: > Since the keys cannot be the same if the ClientHello were to be modified, > what is the risk we are talking about here? I don't know about the crypto > analyses of the TLS handshake, so some insight here would be helpful. But I > agree that having the server process 1-RTT data would help with loss > detection. If there's no real security implication, I'd be in favor of > letting the server process this data. > > On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd wrote: >> >> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson >> wrote: >> > In PR #39, there is a choice: >> > >> > https://github.com/quicwg/base-drafts/pull/39 >> > >> > If a server receives 1-RTT-protected packets before it receives the >> > client Finished message, it could use them. It has the keys. >> > >> > Obviously, if the server depends on certificate-based client >> > authentication it will wait. But that's still a relatively rare >> > occurrence. >> > >> > However, using 1-RTT data before verifying the Finished message could >> > leave the server more vulnerable to an attack where the ClientHello is >> > modified by an attacker. This is something that TLS 1.3 protects >> > against, but only indirectly. The traffic keys are dependent on the >> > content of the ClientHello and so it is likely that modifications of >> > the ClientHello would result in being unable to communicate. But this >> > isn't a strong assertion. The various forms of analysis of the TLS >> > 1.3 handshake have all (I think) assumed that verification of the >> > Finished message is what provides integrity for the handshake. >> >> I don't believe the finished message is necessary for ensuring >> manipulation of the client hello message is detected. >> > >> > In #39, I opted to forbid use of the client 1-RTT data until the >> > handshake completes. I'd like to confirm that this is acceptable. >> > >> > In addition to confirming this, I'd like input on what level of >> > justification is necessary for this in the document. If we believe >> > that this is the right decision, do we need to do anything to prevent >> > someone from pulling out a false start hack because they disagree with >> > this analysis? >> > >> >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> > --001a114734ae35ed1005476c6736 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 31, 2017 3:23 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote= :
The security analyses of= TLS assume receipt and verification of the
Finished message.=C2=A0 It's an obvious intuition that keys depend on t= he
content of the message, therefore tampering would be easily detected.

= I think someone who is more experienced/familiar with the analysis should c= hime in. My understanding is that the ROM quickly gives high probability of= the keys being different and hence the MAC failing, and the Finished messa= ge is there to give an explicit confirmation property.


That said, we've learned that intuition is often wrong in this space, sometimes disastrously.=C2=A0 We don't have an analysis of TLS that ign= ores
the client Finished message.=C2=A0 So unless and until we do, I don't w= ant
to write down anything that isn't known to be safe.

I know that this sucks in subtle ways, particularly in the way that
Ian observed with respect to acknowledgments.=C2=A0 Because we require that=
the Finished is acknowledged with protected keys, we lose the ability
to generate acknowledgments for them.

I see three possible approaches:

1. As I originally suggested, suck it up and don't let the server send.=

2. Don't protect the Finished (it's protected with TLS handshake ke= ys
anyway).=C2=A0 That would allow for acknowledgment in the clear.=C2=A0 That=
requires a tweak to the way that keys are shared, but it's a fairly
simple tweak.=C2=A0 The major downside is that we now have an extra packet<= br> to send, because you can't collapse the Finished message with other
things (like requests).

3. In the hackiest possible way, generate a redundant ACK for the
ClientHello in the clear.=C2=A0 If that could trigger retransmission of the=
first encrypted packet(s), then we'd be OK.=C2=A0 (Sorry, I haven't=
internalized the loss recovery stuff, so I'm not sure if this even
works, we could be back into RTO space here.)

Maybe option 2 is more appealing than appalling.


On 1 February 2017 at 04:17, Jana Iyengar <jri@google.com> wrote:
> Since the keys cannot be the same if the ClientHello were to be modifi= ed,
> what is the risk we are talking about here? I don't know about the= crypto
> analyses of the TLS handshake, so some insight here would be helpful. = But I
> agree that having the server process 1-RTT data would help with loss > detection. If there's no real security implication, I'd be in = favor of
> letting the server process this data.
>
> On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson
>> <martin.thomson@gma= il.com> wrote:
>> > In PR #39, there is a choice:
>> >
>> > https://github.com/quicwg/base-draft= s/pull/39
>> >
>> > If a server receives 1-RTT-protected packets before it receiv= es the
>> > client Finished message, it could use them.=C2=A0 It has the = keys.
>> >
>> > Obviously, if the server depends on certificate-based client<= br> >> > authentication it will wait.=C2=A0 But that's still a rel= atively rare
>> > occurrence.
>> >
>> > However, using 1-RTT data before verifying the Finished messa= ge could
>> > leave the server more vulnerable to an attack where the Clien= tHello is
>> > modified by an attacker.=C2=A0 This is something that TLS 1.3= protects
>> > against, but only indirectly.=C2=A0 The traffic keys are depe= ndent on the
>> > content of the ClientHello and so it is likely that modificat= ions of
>> > the ClientHello would result in being unable to communicate.= =C2=A0 But this
>> > isn't a strong assertion.=C2=A0 The various forms of anal= ysis of the TLS
>> > 1.3 handshake have all (I think) assumed that verification of= the
>> > Finished message is what provides integrity for the handshake= .
>>
>> I don't believe the finished message is necessary for ensuring=
>> manipulation of the client hello message is detected.
>> >
>> > In #39, I opted to forbid use of the client 1-RTT data until = the
>> > handshake completes.=C2=A0 I'd like to confirm that this = is acceptable.
>> >
>> > In addition to confirming this, I'd like input on what le= vel of
>> > justification is necessary for this in the document.=C2=A0 If= we believe
>> > that this is the right decision, do we need to do anything to= prevent
>> > someone from pulling out a false start hack because they disa= gree with
>> > this analysis?
>> >
>>
>>
>>
>> --
>> "Man is born free, but everywhere he is in chains".
>> --Rousseau.
>>
>

--001a114734ae35ed1005476c6736-- From nobody Tue Jan 31 16:23: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 8AAF7129660 for ; Tue, 31 Jan 2017 16:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 eO4q1NoPwKDr for ; Tue, 31 Jan 2017 16:23:57 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 3646E12963A for ; Tue, 31 Jan 2017 16:23:57 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id v96so48908234ioi.0 for ; Tue, 31 Jan 2017 16:23:57 -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=mm3bJZa1RmM0O1DO1DqCwVo80tg7vXyv6BxMIPurzEQ=; b=bnjiOZsSndKrodJ86gSQs5S8egO34VE6hkNoFBkBZHv5nX8CEtDzlgP0fQJt/RUUjn hx9XYlO87c3uRiCfjszQyUFdWBOnU/pCYN2xhpxPtjvy0Ivz5dUhEJTAmw3/jGps4jWy v48qYZVshU5WIsPFa6V8pP51Zm8RvZLT5eQcqJH0EMt53xck6nPCwMuem7+lVM0CDi08 jDBVJPA9WYm8rI6WjafBilNos6fHg7hOgFw5XLA/gDpqag2Xj9Q68YrZSDP/8oF7ApTK XLBPfJwibXxD7HtaFo1Iiryh4iOJ+JLdzdL8f+Qq6jWJ3/36IHnh62UuRDpSE0u1iLjj j4Tg== 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=mm3bJZa1RmM0O1DO1DqCwVo80tg7vXyv6BxMIPurzEQ=; b=X5ru9oN5KdAecIBO0BqKjGsRTiX6/+H5NzZKQuzV1qZfcPucDwYDNd0o1akf9q2C5+ +qUHs6r4Os1EmtPEoO4MGCjX9TyBfLy7r1frk1ZJGu1QEj2dYCWqxzWyBl6zKxnjosha 81qUPqZMtkGpgQyDsChKy1oVk2l4Ivcd6IVkGTdnuDlo8alUVhbX09rFUrqr7tKaN+PN 8G9qJJQiuGJpAZmyK405DMkElFdsMCAXn3NfF8btV+MzFhUrcjSHWq//mwJnfyGDCrxD dKkSJDgrT859IfItzN0y+bKOqNQCoQ1og86sv5YL3OR8LJnYYlgKzl/sSEAoHC/DoAFo +fQQ== X-Gm-Message-State: AIkVDXKF9PLpUnHYdykrHk++jPQ+00briHAj/++0b8zG13nt+t42x+n8RhNhQoHKQ+ibLhgH0IhR5fC4CKkilTb1 X-Received: by 10.107.34.10 with SMTP id i10mr449413ioi.41.1485908636345; Tue, 31 Jan 2017 16:23:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.112 with HTTP; Tue, 31 Jan 2017 16:23:35 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Tue, 31 Jan 2017 16:23:35 -0800 Message-ID: Subject: Re: Splitting QPACK To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140ec6870aa4e05476d1041 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Kazuho Oku , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 00:23:58 -0000 --001a1140ec6870aa4e05476d1041 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 31, 2017 at 3:28 PM, Martin Thomson wrote: > On 1 February 2017 at 10:06, Charles 'Buck' Krasic > wrote: > > Ok I get it now. For the header that causes a table insert, it would be > > ill-advised to use a hpack literal on the headers stream. There's no > point > > guarding HoL blocking among things that that will end up in the same > packet > > anyway. > > The hazard is where you have multiple concurrent uses in short order. > If packetization causes the insert and the reference to appear in > different packets, you have a HOLB exposure. > > As Mike observes, the odds of having a reference that causes an insert > split between two packets is low. Well, depending on how you > construct packets. You can minimize this by generating interleaved > STREAM frames, but that has a bunch of overhead associated with it. > > It all depends on how much you want to spend to avoid stalling in the > case of packet loss. I can imagine using different strategies based > on observed packet loss, but then I can also imagine flying cars and > we all know how common those are. Yea. I can imagine that the trade-offs may play out differently for requests vs responses. Considering the O(100) *requests* example Patrick mentioned. There could be a very good chance that after compression many packets contain headers from several distinct requests. The subset of requests packed into a common packet now share fate, so no point giving up compression efficiency by coding them independently of each other. *if* it were the case that all the requests fit into a single packet, then clearly any HoL avoidance would be strictly losing tactic. In the *response* direction it is quite different. Suppose the request were for images, such that the bodies were all one or more packets large. If the bodies were consistently written along with the corresponding response headers, the chance of two response headers sharing fate (by virtue of serializing into the same packet) may be effectively zero. In that case, having the response headers encoded independent of each other could be quite valuable (still modulo compression efficiency). We clearly need some measurements... -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1140ec6870aa4e05476d1041 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 31, 2017 at 3:28 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 1 February 2017 at 10:06, Charles 'Buck' Krasic <ckrasic@google.com> wrote:
> Ok I get it now.=C2=A0 For the header that causes a table insert, it w= ould be
> ill-advised to use a hpack literal on the headers stream.=C2=A0 =C2=A0= There's no point
> guarding HoL blocking among things that that will end up in the same p= acket
> anyway.

The hazard is where you have multiple concurrent uses in short order= .
If packetization causes the insert and the reference to appear in
different packets, you have a HOLB exposure.

As Mike observes, the odds of having a reference that causes an insert
split between two packets is low.=C2=A0 Well, depending on how you
construct packets.=C2=A0 You can minimize this by generating interleaved STREAM frames, but that has a bunch of overhead associated with it.

It all depends on how much you want to spend to avoid stalling in the
case of packet loss.=C2=A0 I can imagine using different strategies based on observed packet loss, but then I can also imagine flying cars and
we all know how common those are.

Yea.=C2= =A0 I can imagine that the trade-offs may play out differently for requests= vs responses.

Considering the O(100) requests<= /i> example Patrick mentioned. =C2=A0 =C2=A0

There= could be a very good chance that after compression many packets contain he= aders from several distinct requests. =C2=A0 The subset of requests packed = into a common packet now share fate, so no point giving up compression effi= ciency by coding them independently of each other. =C2=A0 *if* it were the = case that all the requests fit into a single packet, then clearly any HoL a= voidance would be strictly losing tactic.

In the <= i>response direction it is quite different.=C2=A0 Suppose the request w= ere for images, such that the bodies were all one or more packets large. = =C2=A0 =C2=A0If the bodies were consistently written along with the corresp= onding response headers, the chance of two response headers sharing fate (b= y virtue of serializing into the same packet) may be effectively zero. =C2= =A0 =C2=A0 In that case, having the response headers encoded independent of= each other could be quite valuable (still modulo compression efficiency).<= /div>

= We clearly need some measurements...

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

--001a1140ec6870aa4e05476d1041-- From nobody Tue Jan 31 17:43:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DAB1296CE for ; Tue, 31 Jan 2017 17:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 x2jxKT_EYFdk for ; Tue, 31 Jan 2017 17:43:43 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA8F1296A0 for ; Tue, 31 Jan 2017 17:43:43 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id c85so15984925wmi.1 for ; Tue, 31 Jan 2017 17:43: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=kD9fnW+Gi5xO26R2qztMw5QbDh3pF/kCANDl7hltFtQ=; b=GbzKZMHzqfEQ7zhJ0J7jbflPKBMy72qQzRDrWJAu+HhIC0+4DzCgJG032116E2SuuP fB17L1/MaYZY10nT7HLkTC5389Jr8cCHx+A4+1r3efBEJP7zV1w4x2I7JAWwmBRa7vH5 b/teLqBJqrw8NUrAX2gbql3CP2HmoSmVetxBi1VskvVsUwtViDyzGGI2gb8HA7FltiyD WVxyinT8ESAhgvfdWNQrHOQyCzmwjW8B9bVDn8mSt1uPGPNxnhKrOAYe6x+7Pg7JKs2Z YxRxerN7D+dUeAm8GJavgLnUoJ++cskJv9Sey/Gv3jX0c28tqak9sobyZTF2J+35w54Y /h6g== 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=kD9fnW+Gi5xO26R2qztMw5QbDh3pF/kCANDl7hltFtQ=; b=m0T36RlNsNc9+77T1EHkXzeVUR265WVsAzLj0sYp1DqHY1VVpF0EUD5ivo6CR/xp5F s3dfi1TmCZQgqbfVY8d8lb7Csld+ecPgfRTKyA6FlQ/QlJPlS1FinQdADvtIJFAms22A MghGLEP0JW1ZdJPRK8aYZzmUGVAZs9BoHpF0FoL31FboYlvj1q0Jr68RwcfxpX65gx7d SafDG+uBrfhi5/YLsiJifIubn86Ga0DuDB4z6en20vYG9pU9FTfvZSJFrMP+igJOri8w NMjfDaWskRjT5VcEzuXsnnLs80VfJ3V/byp08SSdMWd8c18VGpsVAxNVpNVr5syiFSSj /zCA== X-Gm-Message-State: AIkVDXLC6tkPSUTSLGnt3FQQJUSoSSOEfNJjqXbHwhF46/wYElNqgFYUN/l5mqkkvycbyYQxPXhv1XUyXnfjyP9v X-Received: by 10.28.15.202 with SMTP id 193mr513489wmp.99.1485913421631; Tue, 31 Jan 2017 17:43:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Tue, 31 Jan 2017 17:43:40 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Tue, 31 Jan 2017 17:43:40 -0800 Message-ID: Subject: Re: Consensus notification: QUIC advertisement description (#87) To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1145ac32aa29d305476e2d92 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 01:43:45 -0000 --001a1145ac32aa29d305476e2d92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As I read this, it make two changes with respect to what Google is currently doing: Old: Alt-Svc: quic=3D=E2=80=9C:443=E2=80=9D;v=3D=E2=80=9C32,33=E2=80=9D New: AltSvc: hq=3D":443";quic=3D1;quic=3D51303334=E2=80=8B So it renames v=3D to quic=3D (and changes the format somewhat) and renames quic=3D to hq. Am I correct in understanding that a server that wanted to advertise QUIC to both "old" and "new" clients could do: Alt-Svc: quic=3D=E2=80=9C:443=E2=80=9D;v=3D=E2=80=9C32,33=E2=80=9D, hq=3D":= 443";quic=3D1;quic=3D51303334=E2=80=8B Cheers, Ryan=E2=80=8B On Tue, Jan 31, 2017 at 1:28 PM, Mike Bishop wrote: > This issue tracks the > definition of HTTP/QUIC=E2=80=99s ALPN identifier and the version-negotia= tion hint > to Alt-Svc. Text was originally proposed in PR #90 and incorporated in > draft -01. > > > > During the interim in Tokyo, we agreed to use quic=3D instead of v=3D, si= nce > the format has changed from Google=E2=80=99s existing use, and because v= =3D is a bit > generic. This change, along with some editorial feedback, is in PR #235 > . > > > > I=E2=80=99d like to get more eyes on it, and if there=E2=80=99s still con= sensus, merge the > change and close the issue. > --001a1145ac32aa29d305476e2d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I read this, it make two changes with respe= ct to what Google is currently doing:

New: AltSvc: hq=3D":443";quic=3D1;quic=3D51303334= =E2=80=8B

So it renames v=3D to quic= =3D (and changes the format somewhat) and renames quic=3D to hq.

Am I correct in understanding that a server th= at wanted to advertise QUIC to both "old" and "new" cli= ents could do:

Alt-Svc:=C2=A0quic=3D= =E2=80=9C:443=E2=80=9D;v=3D=E2=80=9C32,33=E2=80=9D,=C2=A0hq=3D":443&qu= ot;;quic=3D1;quic=3D51303334=E2=80=8B

<= /div>
Cheers,

Ryan=E2=80=8B

On Tue, J= an 31, 2017 at 1:28 PM, Mike Bishop <Michael.Bishop@microsoft.com= > wrote:

This issue tracks the definition of HTTP/QUIC=E2=80= =99s ALPN identifier and the version-negotiation hint to Alt-Svc.=C2=A0 Tex= t was originally proposed in PR #90 and incorporated in draft -01.

=C2=A0

During the interim in Tokyo, we agreed to use quic= =3D instead of v=3D, since the format has changed from Google=E2=80=99s exi= sting use, and because v=3D is a bit generic.=C2=A0 This change, along with= some editorial feedback, is in PR #= 235.

=C2=A0

I=E2=80=99d like to get more eyes on it, and if ther= e=E2=80=99s still consensus, merge the change and close the issue.


--001a1145ac32aa29d305476e2d92-- From nobody Tue Jan 31 17:50: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 AD70F12970F for ; Tue, 31 Jan 2017 17:50:11 -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 Rpu5qh85iMXf for ; Tue, 31 Jan 2017 17:50:10 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 70022129706 for ; Tue, 31 Jan 2017 17:50:10 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id w20so182614740qtb.1 for ; Tue, 31 Jan 2017 17:50:10 -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=ubu/FxNuT0Nf+K1unG5yZkXjgPlxJTQMGbx7MP98u5k=; b=IAal1EQzsMWn1T7N6ZYJ7/d499ajcsxtshmNeIwjc2ogotyD2RLX2h8CUAu7wGfhLI 4lxliC3H27RkVoqH3XRtAJkP9Dd+hg5aHIoR53bl4Z/c1ijrFEH3rEWNlBgFrI0z/wa8 2e6/dR1XOKStjT2SOvDk/jEavxNm1FDYobAnEEMuVxZM/DBQPgKyQ6ATFPhvNW+x/BSC OVNaY1ZC9uVUckB0AjFBzlDj2prZwRiWnk+6N6ZYEyrLGAt/f1t3i1h/eipfqSgPKE6s DQ8SApNK1P61TPMhzWgg/gVOAMbP9T5bTnYf94L9rRh2Uf91ncdvFkIEeXsY8rdHBwL6 lK/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ubu/FxNuT0Nf+K1unG5yZkXjgPlxJTQMGbx7MP98u5k=; b=lVft4jwVzdubow5Hu4/MOVacYHA+9zY8hTX/3D2GZlRvEwmvEGy4f3AtiDa3Gi27QD 6cSPSojblH2JpoJgFDmy7GDZ2sI9mQRi2Jy6iTVXiWKOlFi4mHBhmEvUcxTYw/Ft14Uk K6DGxDlAFYDTKVXmU6S7IoI3lumlAF1uptWyJypOQBOZ6PZ8F2s2ywTZJSuYd31G+M3G BUaNJVI4r8cL0M/9nmM2G3wncoHiL6A2Zmj2gYryuLbPXrp2EM0AC50AUxUBacadBi7p Aur6HitSwEJtekm5HDQaYcOYbRVHYjgs8ykIPyA2s9qOtn1TVoRih6FT3NC1rzqOL3bG qo2g== X-Gm-Message-State: AIkVDXJjSgohSU7zlYGxhtI4WQKJE9EMDEPRCvtM5K8yvHzpGaZH9QaxRWSFfrcYHoau4PPG3dYjXLnAw7wNoQ== X-Received: by 10.200.57.199 with SMTP id v65mr325974qte.13.1485913809574; Tue, 31 Jan 2017 17:50:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 31 Jan 2017 17:50:09 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 1 Feb 2017 12:50:09 +1100 Message-ID: Subject: Re: Consensus notification: QUIC advertisement description (#87) To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 01:50:11 -0000 On 1 February 2017 at 12:43, Ryan Hamilton wrote: > Am I correct in understanding that a server that wanted to advertise QUIC= to > both "old" and "new" clients could do: > > Alt-Svc: quic=3D=E2=80=9C:443=E2=80=9D;v=3D=E2=80=9C32,33=E2=80=9D, hq=3D= ":443";quic=3D1;quic=3D51303334 This is correct. From nobody Tue Jan 31 22:29: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 62A111293F2 for ; Tue, 31 Jan 2017 22:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4noNdLz15py0 for ; Tue, 31 Jan 2017 22:29:19 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4E6120727 for ; Tue, 31 Jan 2017 22:29:19 -0800 (PST) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) by linode64.ducksong.com (Postfix) with ESMTPSA id E72D03A0A3 for ; Wed, 1 Feb 2017 01:29:15 -0500 (EST) Received: by mail-qt0-f179.google.com with SMTP id w20so186589098qtb.1 for ; Tue, 31 Jan 2017 22:29:15 -0800 (PST) X-Gm-Message-State: AIkVDXJ0N4QKPMm6a2JhdzECTKUYsiJhgaq4FJmlfrmUoWhE3e3WvqnP7t16DphtabMby7uoVjPY5DRM4A9zJg== X-Received: by 10.200.52.170 with SMTP id w39mr1213153qtb.123.1485930555668; Tue, 31 Jan 2017 22:29:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Tue, 31 Jan 2017 22:29:15 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Wed, 1 Feb 2017 07:29:15 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Splitting QPACK To: "Charles 'Buck' Krasic" Content-Type: multipart/alternative; boundary=001a1147904aee84a30547722a88 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Martin Thomson , Ryan Hamilton , Kazuho Oku X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 06:29:22 -0000 --001a1147904aee84a30547722a88 Content-Type: text/plain; charset=UTF-8 or to put it another related way - the value of hpack has always been in avoiding cwnd stalls. quic breaks down the old abstractions and an encoder can certainly better take into account cwnd, the amount of data it thinks it will be sending, and how it wants to combine frames in packets. that's pretty powerful in balancing the tradeoffs here. off hand it seems clients doing the o(100) thing would be highly incented early on, but later might not need to accommodate such bursts and would use different strategies.. similarly servers might only use compression rarely. beyond to compress or not, different choices might be made in how tightly each packet is stuffed again based on cwnd. On Wed, Feb 1, 2017 at 1:23 AM, Charles 'Buck' Krasic wrote: > > > On Tue, Jan 31, 2017 at 3:28 PM, Martin Thomson > wrote: > >> On 1 February 2017 at 10:06, Charles 'Buck' Krasic >> wrote: >> > Ok I get it now. For the header that causes a table insert, it would be >> > ill-advised to use a hpack literal on the headers stream. There's no >> point >> > guarding HoL blocking among things that that will end up in the same >> packet >> > anyway. >> >> The hazard is where you have multiple concurrent uses in short order. >> If packetization causes the insert and the reference to appear in >> different packets, you have a HOLB exposure. >> >> As Mike observes, the odds of having a reference that causes an insert >> split between two packets is low. Well, depending on how you >> construct packets. You can minimize this by generating interleaved >> STREAM frames, but that has a bunch of overhead associated with it. >> >> It all depends on how much you want to spend to avoid stalling in the >> case of packet loss. I can imagine using different strategies based >> on observed packet loss, but then I can also imagine flying cars and >> we all know how common those are. > > > Yea. I can imagine that the trade-offs may play out differently for > requests vs responses. > > Considering the O(100) *requests* example Patrick mentioned. > > There could be a very good chance that after compression many packets > contain headers from several distinct requests. The subset of requests > packed into a common packet now share fate, so no point giving up > compression efficiency by coding them independently of each other. *if* > it were the case that all the requests fit into a single packet, then > clearly any HoL avoidance would be strictly losing tactic. > > In the *response* direction it is quite different. Suppose the request > were for images, such that the bodies were all one or more packets large. > If the bodies were consistently written along with the corresponding > response headers, the chance of two response headers sharing fate (by > virtue of serializing into the same packet) may be effectively zero. In > that case, having the response headers encoded independent of each other > could be quite valuable (still modulo compression efficiency). > > We clearly need some measurements... > > -- > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > > --001a1147904aee84a30547722a88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
or to put it another related way - the value of = hpack has always been in avoiding cwnd stalls. quic breaks down the old abs= tractions and an encoder can certainly better take into account cwnd, the a= mount of data it thinks it will be sending, and how it wants to combine fra= mes in packets. that's pretty powerful in balancing the tradeoffs here.=

off hand it seems clients doing the o(100) thing would be hig= hly incented early on, but later might not need to accommodate such bursts = and would use different strategies.. similarly servers might only use compr= ession rarely.

beyond to compress or not, different choices mi= ght be made in how tightly each packet is stuffed again based on cwnd.
<= br>

On Wed, = Feb 1, 2017 at 1:23 AM, Charles 'Buck' Krasic <= ;ckrasic@google.com= > wrote:
<= br>

On Tue, Jan 31, 2017 at 3:28 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 1 February 2017 at 10:06, Charles 'Buck' Krasic <ckrasic@google.com>= wrote:
> Ok I get it now.=C2=A0 For the header that causes a table insert, it w= ould be
> ill-advised to use a hpack literal on the headers stream.=C2=A0 =C2=A0= There's no point
> guarding HoL blocking among things that that will end up in the same p= acket
> anyway.

The hazard is where you have multiple concurrent uses in short order= .
If packetization causes the insert and the reference to appear in
different packets, you have a HOLB exposure.

As Mike observes, the odds of having a reference that causes an insert
split between two packets is low.=C2=A0 Well, depending on how you
construct packets.=C2=A0 You can minimize this by generating interleaved STREAM frames, but that has a bunch of overhead associated with it.

It all depends on how much you want to spend to avoid stalling in the
case of packet loss.=C2=A0 I can imagine using different strategies based on observed packet loss, but then I can also imagine flying cars and
we all know how common those are.

Yea.=C2=A0 I can imagine that the trade-offs may play out differently fo= r requests vs responses.

Considering the O(100) requests example Patrick mentioned. =C2=A0 =C2=A0

=
There could be a very good chance that after compression many packets = contain headers from several distinct requests. =C2=A0 The subset of reques= ts packed into a common packet now share fate, so no point giving up compre= ssion efficiency by coding them independently of each other. =C2=A0 *if* it= were the case that all the requests fit into a single packet, then clearly= any HoL avoidance would be strictly losing tactic.

In the response direction it is quite different.=C2=A0 Suppose the= request were for images, such that the bodies were all one or more packets= large. =C2=A0 =C2=A0If the bodies were consistently written along with the= corresponding response headers, the chance of two response headers sharing= fate (by virtue of serializing into the same packet) may be effectively ze= ro. =C2=A0 =C2=A0 In that case, having the response headers encoded indepen= dent of each other could be quite valuable (still modulo compression effici= ency).

We clearly need some measurements...

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


--001a1147904aee84a30547722a88--

On Jan 5, 2017, at 3:31 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:

Hey All,

My = high level comment is that (from the abstract of the transport ID) "QUIC = encrypts most of its headers, thereby limiting protocol evolution=20 to QUIC endpoints only. Therefore, middleboxes, in large part, are not=20= required to be updated as new protocol versions are deployed".

unencrypting data in order to have middleboxes = be updated for new protocol versions (and their options!) is really an = anti-goal of this work. This is for both protocol evolution and = application confidentiality.

Sure.  We understand the sentiment. Our goal = was to see how QUIC could be provided more assistance from the network. = Priority plays a big role in classifying the streams and the stream id = for providing better feedback and state machine establishment. As for = protocol evolution, as long as its a tlv format and has backward = compatibility, it should not be an issue. This could be a separate = header section just for network elements and optional. We can add = capability flags for the same. Would this be something you would be open = to  - an optional header.

We = are viewing QUIC as something that will eventually replace TCP for a lot = of applications. We currently can parse the TCP packet and have state = machines implemented for it in our network elements. Unfortunately there = is no priority set by each packet.  Also stream id, would provide = better analytics on the network on a per connection = basis. 


This is a strong end to end design decision - if you = think the value of a transport protocol instead comes from network = signaling you're going to disagree with a number of design decisions. = The open questions are often about how _more_ confidentiality and = integrity can be created (i.e. is it feasible to make the connection = identifier less trackable, and how a public reset can be made less = public (or if its even needed at all)) - the public stream id proposal = blows against that = headwind.

Interesting.  The session could still be = identified using the 5 tuple for sure.  But looks like the approach = is to hide everything possible for security reasons. Are there no = thoughts on getting network assistance where possible ? What about = priority per packet. Is that a cause for concern as well. The protocol = can get feedback as well as assistance from the network.

Others have made interesting comments about the = relationship between frames and packets and there are at least 2 github = issues open on priority and retransmission - Christian also makes a good = comment in this thread about congestion control and its embedded = assumptions. Making these elements opaque to the network lets the = transport protocol come to a consistent internal resolution to these = questions without depending on path behavior which is aligned with the = goal in my first paragraph.

hth = explain my thoughts. Again, thanks for taking the time to write it down. = I know that can feel thankless, but it really helps everyone understand = crisply what is being discussed and I sincerely appreciate it.

Thank you again for taking the time to go through = your different concerns.  We would like to follow up on this and = see if the group is open to an optional network header element and = priority. This way only clients can choose to avail this assistance if = needed. This would be a good use-case in SD-WAN scenarios.

Thanks,
Abilash




-Patrick


On Thu, = Jan 5, 2017 at 1:20 PM, Abilash Menon <amenon@128technology.com> wrote:
Patrick,

More replies inline = <amenon>

On Jan = 5, 2017, at 11:50 AM, Ritesh Mukherjee <rmukherjee@128technology.com> wrote:

Hi = Patrick,
 
Please = see inline=E2=80=A6..
 
Ritesh
 
 
From: Patrick= McManus [mailto:pmcmanus@mozilla.com] 
Sent: Thursda= y, January 5, 2017 11:03 AM
To: Ritesh = Mukherjee <rmukherjee@128technology.com>
Cc: IETF = QUIC WG <quic@ietf.org>
Subject: Re: = soliciting feedback on draft-abilash-quic-network
 
Ritesh - thanks for taking the time to write your thoughts = down and sharing them.


The draft calls for removing encryption of the stream ID and = also adding a priority system at the transport level that's less = expressive than the h2 one quic has to carry - (also unencrypted).

[Ritesh] The stream ID and = priority are authenticated. Yes =E2=80=93 they need to be unencrypted = for the network elements to optimize performance.

The quic = charter calls for " a UDP-based, stream-multiplexing, encrypted = transport protocol". and "provide confidentiality [..] of both = application data and QUIC header.".

[Ritesh] The entire statement = says =E2=80=9Cdescribe how those keys are used to provide = confidentiality and integrity protection of both application data and = QUIC headers.=E2=80=9D. The charter does not mandate not exposing any = element of the QUIC header even if it would improve = performance.


<amenon> We = would like to understand your concerns as to why this would be a = problem.. The draft calls for exposing some fields in the header so that = QUIC can benefit from the network. These could be made optional for = clients which do not want to avail any network performance = enhancements.

Further, = draft-abilash's security considerations are effectively empty, which = makes me doubt things like traffic analysis, etc have been = considered



[Ritesh] Agreed. It is work in = progress. We have done testing and analysis. We will update it in the = next iteration and suggestions are always welcome.  =


<amenon> Yes. We will update the = draft with more details. Please let us know if there are some specific = cases you would like us to address.


This = doesn't sound like the mentioned draft should be used for changes in the = protocol, though it may provide useful input to the applicability and = manageability = statement.