IETF Logo Mail Archive

Re: Fibonaccing CID lengths

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 23 May 2019 15:18 UTC

Return-Path: <mikkelfj@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 3CF8C120130 for <quic@ietfa.amsl.com>; Thu, 23 May 2019 08:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id powNmwqgrn9g for <quic@ietfa.amsl.com>; Thu, 23 May 2019 08:18:51 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA87120126 for <quic@ietf.org>; Thu, 23 May 2019 08:18:03 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id w33so6382640edb.10 for <quic@ietf.org>; Thu, 23 May 2019 08:18:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=7KTB47IGxxQKgjkcuoIQmJWz1YxEemKbHvN4QOJhCv4=; b=n3qA0PusaBBlqyItApa0hXbCx0xWyRQKPXwNblOhR4yhEJaL+Nq5k8W1Ojbl/h5dya Vy40IhYqr3PleIGBr6pWqs40l7gk6Gp1YdqyENyC2CaatdXdYJ7gneQoo0fak7oCggat 3GyVjQKnyyB1BXBizNHBeynGjlvcKHtsFePEaxXY+79713/gUqYMJemITgrKetAHGiu6 4xFnfHAxgw4gQD08VFpSsk2I6BrNrDG0Mveu7dGz40ep3I6XpxrHX4/5Ix5+2t899aDX q0V3HRJQD+yNYgVYjRNJyEQIGOfQ6gmPVvKir+gRMFxI8fI8gLSDH12HoZa5LETUIZ9Q z+Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=7KTB47IGxxQKgjkcuoIQmJWz1YxEemKbHvN4QOJhCv4=; b=l/eM7wD3PnZSi1PBfuHrOEL/y//hRnalnrhwnUkkmtuwKECAydsoAbBiyfTsAAmkho C36vy8J91AhxTYmG30fPzE+a1WTgAHwBrSF8ifZ8EvrS52yCd5nD9FjuIDGHVd2ODzV5 zgb3NGP/BQPanX/nG7Y+BlxaZnl8EdvNlLlxE0PrshBjMs3urhKjzSlQMrc+lhwS+Oqv ETXNPcfLw1JraNq1MuRm9MrEP61SgrVTuAXCU2ksJX+zbLXmlRtt8PHzY8e6E2uF1CHE 6fTJAS/R3zyx0E3nWpuam4Y1gLtCminVCv4j3Nu+AuTIM9i1RVicgjIVuvvsWuRFwmc5 m6aQ==
X-Gm-Message-State: APjAAAWfU0M7vEzNwzAugCDo9dklvUrRm2dqAw1G2gGelsc9dLx33YMU Q+x+yrGUCmhlCXmR3shtCWelDrr3qpE2k0cncWHLpw==
X-Google-Smtp-Source: APXvYqwRi37m7vOUUk5o35D3hVHGQNrpBfEtAQvI3RRq2K/E74Dg0u7vJ5KI7lyFtgC0kzSZGE9tHSGjVhbKcyIyRnc=
X-Received: by 2002:a17:906:fc02:: with SMTP id ov2mr8751984ejb.22.1558624682022; Thu, 23 May 2019 08:18:02 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 23 May 2019 08:18:00 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAOYVs2rrppV=iyfn=Tfpw_QFyvJo6RtY65S81J5OqL5Tuj9ydg@mail.gmail.com>
References: <20190522141238.GA23472@ubuntu-dmitri> <CAN1APdfBMeKGzsdLR__OLUHQ7pg=YM76C2Qxn6VDCXu680JQyA@mail.gmail.com> <ab64bdc2-805b-a86d-c525-41d076deac40@huitema.net> <20190522200406.GA28789@ubuntu-dmitri> <CANatvzx4rxk6UU48omk-EfpoYzfg_zWR+N49zMWi_5rv722uQg@mail.gmail.com> <20190523082129.GA6712@ubuntu-dmitri> <CAPDSy+6SpSjSeiMOjZWbC2x4mnpmsPf3PQq08s6KBru3aSRt0w@mail.gmail.com> <CAOYVs2rrppV=iyfn=Tfpw_QFyvJo6RtY65S81J5OqL5Tuj9ydg@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 23 May 2019 08:18:00 -0700
Message-ID: <CAN1APdcDccD49XJp=HfhPQgdEmb4pcPtNtxH81xX1NPwe1K1rA@mail.gmail.com>
Subject: Re: Fibonaccing CID lengths
To: David Schinazi <dschinazi.ietf@gmail.com>, Marten Seemann <martenseemann@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, Christian Huitema <huitema@huitema.net>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000829dcc05898f96ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_R_G8ezIoaaTJa2y-NNuUb247qs>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 23 May 2019 15:18:54 -0000

I’m all for the 8 bit lengths, but I don’t see how they prevent
ossification of the first two bits?

Regardless this kind of ossification is not important since middle boxes
will lock down on CID lengths they support and mistreat other lengths. The
length field is just one part of this.



On 23 May 2019 at 17.13.51, Marten Seemann (martenseemann@gmail.com) wrote:

Using an 8-bit encoding would also prevent ossification of the first two
bits of each connection ID length field. These bits would always be 0 (in
QUIC v1), since connection ID lengths above 48 can never occur.

On Thu, May 23, 2019 at 4:08 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> This encoding would be harder to deploy on our servers than having two
> 8-bit lengths. The only benefit of this is saving 8 bits on long headers,
> and that's not worth the complexity.
>
> On Thu, May 23, 2019 at 9:21 AM Dmitri Tikhonov <
> dtikhonov@litespeedtech.com> wrote:
>
>> On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuho Oku wrote:
>> > 2019年5月22日(水) 21:04 Dmitri Tikhonov <dtikhonov@litespeedtech.com>:
>> > > While the example is lighthearted, the proposal is serious: that is,
>> > > remap 0 - 15 values of the nybble to a different set.  Do we need to
>> > > represent every intermediate number between 0 and 48 (the maximum of
>> > > the current PR)?
>> >
>> > The question is what you gain by compressing the length to 4 bits.
>> >
>> ----- 8< --- 8< --- 8< ---
>> >
>> > So, what's the benefit?
>>
>> Smaller change to the drafts -- and existing code.
>>
>>   - Dmitri.
>>
>>

v2.23.0 | Report a Bug | By Email