Re: Long Headers and Version Negotiation

Martin Thomson <martin.thomson@gmail.com> Mon, 08 January 2018 03:33 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37BF126DC2 for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 19:33: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 6E31-i6pd4ll for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 19:33:01 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145141201FA for <quic@ietf.org>; Sun, 7 Jan 2018 19:33:01 -0800 (PST)
Received: by mail-oi0-x234.google.com with SMTP id y141so163579oia.0 for <quic@ietf.org>; Sun, 07 Jan 2018 19:33:01 -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=YO+neVuDnwSPMEe2pS8l8xH2nDKVCD01SvT6wlRlYIo=; b=ekBpAcyB4BZU1KrvBm8cWjBNITq484r88c36X6+pR4QXyl6JV9Dn1UCr/ZDKJx8mSE Z6JDm/aG+Kw+pp4GR6YDpG/W4+yT0czP4X+I3fbR08dWjBwGCRCAgA+KsZmap9hBtXls 96tIz2evpoO052Iq1CfuQw6G/9r/IQThC7Q90dHexCJD8yjRDyNORs6mAlZlFajpsyqq 2r8kivyYWq2Zv8je3m2gh3GqGDJ3gsizggagZ0fQOKtxTGiGfjih3eAQdVLjYwyZCg68 jhJwvJ3V/sJld93RCHIyCFENiHs67wpC45MFETE4xUJI3uewcpjZIXnoe9QU3oTPpre1 YXWw==
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=YO+neVuDnwSPMEe2pS8l8xH2nDKVCD01SvT6wlRlYIo=; b=jurEMkm1S7XQcywYnNP5HKYlNiVfoEVftNHBPs9akpmsX4pY6eAqQiPo9IqAVFA9pt FqVbEo+wwJ1/vh2d38PeTS0nvFTZ7KJBebh8wnLMltCGseYyxf7b2+RiEP97i+rNb71j qQxGp3UJBCSq1Co8lDH28WR6nZSp7Jt2+Ay97Mn14mz4GHNKGYc/vhLBXcN8ndhaMAy7 SjJhRLOuqbLrdpqZjr8VLl1qrI9+6fmFeVGRNRevUbIXxbvf/FzU3KM+Skqqcm0YKYrw rXQ/UEZtQiwDfZ1SOE73xLJQZRUdSFBX1E6Q9MDFb8WyYHkeq80wC3H1aexHQNnSZ3/Y bZow==
X-Gm-Message-State: AKGB3mIV+NwvCaSZhWts2/yak1V7VZMW/8LfLH+91x+5Y7FIUNi0NvoO JUL3fhO/+rQrZB8VKXN4uNTeahjxd4X/dmJUShc=
X-Google-Smtp-Source: ACJfBouhuEL733IWI/iH3oWy85BXoFzujB+zhWhZRQodLZPEwCPids1Mf2JQ3HlrTx5oe+SPc1MqWIy1jXPQMfbHlIg=
X-Received: by 10.202.234.214 with SMTP id i205mr5581725oih.84.1515382380329; Sun, 07 Jan 2018 19:33:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.39.16 with HTTP; Sun, 7 Jan 2018 19:32:59 -0800 (PST)
In-Reply-To: <FB5E9997-E32A-4506-A76D-4AA4F4EFB34D@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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 08 Jan 2018 14:32:59 +1100
Message-ID: <CABkgnnUj2rz5t_6tcdoORAtaxZqNb6O3_onPWAoQDxHoRJuxVw@mail.gmail.com>
Subject: Re: Long Headers and Version Negotiation
To: Christian Huitema <huitema@huitema.net>
Cc: Martin Duke <martin.h.duke@gmail.com>, Nick Banks <nibanks@microsoft.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/L-XSfhMmgXYGJTfIx7rNYMc9Czg>
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:33:02 -0000

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.

> 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.