IETF Logo Mail Archive

Re: Fibonaccing CID lengths

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Wed, 22 May 2019 20:04 UTC

Return-Path: <dtikhonov@litespeedtech.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 74040120117 for <quic@ietfa.amsl.com>; Wed, 22 May 2019 13:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSKnxuWdR7pX for <quic@ietfa.amsl.com>; Wed, 22 May 2019 13:04:18 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 C71E212006E for <quic@ietf.org>; Wed, 22 May 2019 13:04:17 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id d10so2349632qko.4 for <quic@ietf.org>; Wed, 22 May 2019 13:04:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YiE4enjHOA6yJivKw5aU+OcnxvoxNCq82IFnEiK4C2A=; b=1fx447C2LKptm1U6gqO9KWnAQSVGcRXptM1/Af/rJjsUktqx+gujLPcxZ54kOi0pV9 vDn8Ahm0LrMzuInX/cpkeQt1cycgxwvGQu7+gcmbVLF8C/jOrB0QvN/T90n5sSByhi7t /KcX8KkcKSq2OZjhfKWSpaHAuJtMKSb49Vu9JDZOvQ7mwBvQACFjh2nIwsCh4xeALcpO /67fCtvJ99QY6ZSGGiwIIpu5A4T056MKP+KJA2xBjytvFG9Mf+7DrC2CrAlAXMPmJV1d vOa9xlgNUhDX2fLc6kWfF1tTmmZD08OCTz0lwsbJnhAZX2/JdAjCpI3MrF2MoOQc+A1C tm9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=YiE4enjHOA6yJivKw5aU+OcnxvoxNCq82IFnEiK4C2A=; b=WCO7XhOeg4sLpXVA1EMiXrWGHDz4KnQ2aD5WmUWPnQC96S/E1sY8YVyeYJCTDyxaQu dzwvtU2mmA6y/LMwcnYLd1GMNesrhX251sJFp3CfT6cLjIExisdR7iBPzC1MdyxyJi/a cdkvHmRKjbcgK3+aeI3giFOcRfN5oN1KD8d9mR46mLkZ00kUaRNkTQYwWCxRqgPxJNvh ubqFShKTNd3SchX4rtWM3TuaryBfNuGksaknvLeaTUk8PjZ8WSuNU6b53Af7CuOGYcAd igj+6QIA8T+hWftXe8zKMvLa2+p3QWng6rg4rcRcJasHK8RkmEA2T6HjNa3llX58BcUF XbBw==
X-Gm-Message-State: APjAAAXLk62xehHsYNzCO9GhJWTUONv8shB3Rz+nDP13YCw6RiuPtmYT 4h0lhfB68mbWvVk9H6qe9JWwHg==
X-Google-Smtp-Source: APXvYqzfGw7lqZi5q8NPaTNQnv9heEeBnyXg4+EItN4guKjyWIn9lebJxxGtD+i/aKXTkCrH7rmpvQ==
X-Received: by 2002:a37:5945:: with SMTP id n66mr69295718qkb.295.1558555456995; Wed, 22 May 2019 13:04:16 -0700 (PDT)
Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id k53sm12559473qtb.65.2019.05.22.13.04.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 13:04:16 -0700 (PDT)
Date: Wed, 22 May 2019 16:04:07 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Fibonaccing CID lengths
Message-ID: <20190522200406.GA28789@ubuntu-dmitri>
Mail-Followup-To: Christian Huitema <huitema@huitema.net>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>
References: <20190522141238.GA23472@ubuntu-dmitri> <CAN1APdfBMeKGzsdLR__OLUHQ7pg=YM76C2Qxn6VDCXu680JQyA@mail.gmail.com> <ab64bdc2-805b-a86d-c525-41d076deac40@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ab64bdc2-805b-a86d-c525-41d076deac40@huitema.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Z6-YFOqUrgmfubLBpV4lqxRYHPc>
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: Wed, 22 May 2019 20:04:19 -0000

On Wed, May 22, 2019 at 10:19:38AM -0700, Christian Huitema wrote:
> Yes, that looks like a proposal that we should seriously consider.

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)?

What if instead we do the following:

     0 -> 0
     1 -> 1
     2 -> 2
     3 -> 3
     4 -> 4
     5 -> 6
     6 -> 8
     7 -> 12
     8 -> 16
     9 -> 20
     10 -> 24
     11 -> 28
     12 -> 32
     13 -> 40
     14 -> 48
     15 -> 64

This is as valid an approach as encoding the length in 8 bits and
having to deal with invalid values or using a varint and having
to deal with even more invalid values.

  - Dmitri.

v2.23.0 | Report a Bug | By Email