Re: [quicwg/base-drafts] consider making the varint encoding unique (#2299)

MikkelFJ <notifications@github.com> Sun, 06 January 2019 19:40 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C14130DBE for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 11:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.064
X-Spam-Level:
X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 GbhOPdrcK_1b for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 11:40:57 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECDF130DED for <quic-issues@ietf.org>; Sun, 6 Jan 2019 11:40:56 -0800 (PST)
Date: Sun, 06 Jan 2019 11:40:55 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546803655; bh=xfk1Jkj/JaUzdIJV5oP1WUMkZymhczmu6kbxMJtaOdg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wzvgogUzO40bwGx26r/vAkwXsc8TkojcIV33zOnzCy6f683pfr76Hvkgr8eYkQqvj GhgY7hEorulCfNjy/aQUUqfMY5r88+VHLyoBYFW/VBjWYb5KMu3ryBJfa9KTFUevuT PcSPMJmeXuYSqg9U9E8XoAQ1RCt/8iS1AAQqxki4=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2aa37a8fedee0e438eceec4bb721f4abbd8ff46592cf00000001184a1bc792a169ce179e43e2@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2299/451768597@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2299@github.com>
References: <quicwg/base-drafts/issues/2299@github.com>
Subject: Re: [quicwg/base-drafts] consider making the varint encoding unique (#2299)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c3259c7f04ca_39bb3fc7596d45c47910d7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/imD21_vWUo2S0YEN3WdZNgynFe0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Jan 2019 19:40:59 -0000

> Looking up at the requirement for shortest possible frame type, I don't understand why that's even necessary to require this. 

This is because it allows for efficient switch constructs when decoding the frames. This avoids additional complexity during decode. There is difference between enumerations such as frame types, and length values. Enumerations should be uniquely encoded whereas it could be argued that lengths need not due to the memmov issue.

I'm not sure that vast overhead goes to decryption because this is typically 3 cycles per byte so you could easily double the time overhead if you have many small frames that are processed inefficiently.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2299#issuecomment-451768597