Re: Long Headers and Version Negotiation

Christian Huitema <huitema@huitema.net> Mon, 08 January 2018 03:50 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E07126D74 for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 19:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTrJfMwugcGt for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 19:50:02 -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 3EB541200C1 for <quic@ietf.org>; Sun, 7 Jan 2018 19:50:02 -0800 (PST)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eYORk-0002e7-3P for quic@ietf.org; Mon, 08 Jan 2018 04:50:00 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eYORc-0007F2-3V for quic@ietf.org; Sun, 07 Jan 2018 22:49:56 -0500
Received: (qmail 29015 invoked from network); 8 Jan 2018 03:49:51 -0000
Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <martin.h.duke@gmail.com>; 8 Jan 2018 03:49:51 -0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15C153)
In-Reply-To: <CABkgnnUj2rz5t_6tcdoORAtaxZqNb6O3_onPWAoQDxHoRJuxVw@mail.gmail.com>
Date: Sun, 7 Jan 2018 17:49:48 -1000
Cc: Martin Duke <martin.h.duke@gmail.com>, Nick Banks <nibanks@microsoft.com>, IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E389B9E7-C716-4963-8E2B-1E4C86F3D7B8@huitema.net>
References: <CAM4esxRroE5rOXEHgqJ-_5Vdm-=odN7VmWBweKQgTnT5pU87XA@mail.gmail.com> <BN6PR21MB01788D37BFE5700EB00F392AB31C0@BN6PR21MB0178.namprd21.prod.outlook.com> <CABkgnnWUqv2Y2UCaq6EF1cBBKiAzgvua-KQzobPMVHZBcpXvXw@mail.gmail.com> <CAM4esxQzrvwBwFr5tTk9ni+-gEs7xzXvzHp1ADy847w4SrNTwQ@mail.gmail.com> <FB5E9997-E32A-4506-A76D-4AA4F4EFB34D@huitema.net> <CABkgnnUj2rz5t_6tcdoORAtaxZqNb6O3_onPWAoQDxHoRJuxVw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Long Headers and Version Negotiation
X-Originating-IP: 168.144.250.215
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.29)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5l7jLt63W30jHr4DCwWF0VYXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fu9ZH5f4mJwEsL8wCNEtMkDB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31WoCGUWNgo50bBZN3FfqI2VItAPyqRyV95ZNrHd7vkN RtYO6A0DBVvo3Pds5mJVTPXh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GYnRqIO2TPU1F0bSG6T2DJZnHEeB4hpRrmo/duzUUp/JM XkWanlHHapN24HIulP+VM6pft8V9tVB0HhUp891ZxXLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+G45OmBNdsUklj47JM2Zh1oj2lB9TLiDMfXuvSrucRXry8B6sEcpHNQcjlAOoToGvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/oMFGViO8Pm030bvbLi8tg1x1FoM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jan 2018 03:50:05 -0000


> On Jan 7, 2018, at 5:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
>> On Mon, Jan 8, 2018 at 2:12 PM, Christian Huitema <huitema@huitema.net> wrote:
>> About 0xFF invariant -- that was one of the issues we found during the
>> December 18 interop. The first byte in the VN packet is unspecified so
>> picoquic was setting it to 0xFF. Legit, but somewhat unexpected.
> 
> That's why we have these interop things.  The question is whether it
> is surprising enough to warrant a change.

Eh eh...
> 
>> Another point about VN storms. Servers can of course implement some kind of
>> pacing. They should also only send VN in response to packets that are at
>> least 1200 bytes, since CI must be at least that.
> 
> From Section 7.1:
> 
> For servers, packets that aren’t associated with a connection
> potentially create a new connection. However, only packets that use
> the long packet header and that are at least the minimum size defined
> for the protocol version can be initial packets.

So if we just suggested that 0-RTT packets should be shorter than the minimum size, we would be covered.