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

Nick Banks <notifications@github.com> Sun, 06 January 2019 18:13 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 DF61C128CB7 for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 10:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 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_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 XL9hvGz7xoxm for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 10:13:47 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE3C128B14 for <quic-issues@ietf.org>; Sun, 6 Jan 2019 10:13:46 -0800 (PST)
Date: Sun, 06 Jan 2019 10:13:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546798425; bh=pMkq26YYOAbK8qreMa1jtuIP5hedWXERphjB7U3X3KQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=e/p/wFUyC/6iN92Vmr38ENGNGs+J+l9i8owkfvb0Y9eNz0Rr3Hd+QnccREUL+2YxR df2BIJ+BWkqxkFu9TbiysNRiNKOCa2KRKFGsw1vyqXpyD+yeUEKuNekHmSmv6ZwNk9 WK+W0shu0nbgu3+nOcE32izl4glbxoUxUpsMgPvQ=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab3fb191468ca070c2f8a2ef95a882c2ca15c2dcd992cf00000001184a075992a169ce179e43e2@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/451762140@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_5c3245592ee19_343e3fc6f42d45c47346a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/-5axunImpi06emVL8u7yeW72qQQ>
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 18:13:50 -0000

In WinQuic we have a special function just for encoding a varint explicitly two bytes that we use for the payload length in long headers. It would be **extremely difficult** to update this code to always use the shortest encoding without having to memmove the entire payload after it has been written to the packet buffer.

Looking up at the requirement for shortest possible frame type, I don't understand why that's even necessary to require this. Obviously it's more efficient on the wire, but as far as implementation processing efficiency goes, it would make little difference in the grand scheme of things (a majority of all CPU will be spent in encryption/decryption). So, we can recommend the shortest encoding, but I don't think we should kill the connection if a particular implementation does always use that.

I'd prefer to leave the varint as is and remove any requirements for a particular encoding length.

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