The first octet
Martin Thomson <martin.thomson@gmail.com> Mon, 06 August 2018 05:55 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 5BA8A130DFE for <quic@ietfa.amsl.com>; Sun, 5 Aug 2018 22:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_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=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 C844oJUcASif for <quic@ietfa.amsl.com>; Sun, 5 Aug 2018 22:55:47 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 3976A130DE6 for <quic@ietf.org>; Sun, 5 Aug 2018 22:55:47 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id j205-v6so20124428oib.4 for <quic@ietf.org>; Sun, 05 Aug 2018 22:55:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DQ8gmgZcZFfbffkfIV9HjPbr4eCOZqjxpwlVw5HNr1o=; b=AykLj0xzSVkarCGuqgXRtSjTUgYpP5QLXhOvHmd1LH2tCougKdrb7MvbZRfr2gWky8 3+hvXl0/YR29GGCZ+alObhZ4rk7vnPbFyPlfOvMJ23kZ71H90iNKwUE86D5oJG+ZPTQw VwdhLYoOd8GAxQ+xuuwkQqTbbtRwIFrpNXs5kbMpnIGn21ZbBc8RNLNH15lsTt4z/fXN UAFOpVtlt+cp2Fnfce6T9izdWCQbvoAgJtccP9Jo6FIw36BPwnI1/L/W+6NEaGW8oXf8 cSYDyi9Jnu+8Mt4RdwJ/xjaLrJC51evsv6tlGwspUSMcYfH66GTQU+7nqxtpCSW+qtJ1 dT3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DQ8gmgZcZFfbffkfIV9HjPbr4eCOZqjxpwlVw5HNr1o=; b=kEEeBSKF2A9/iTbvW5AAFoh3JhP6J1M4J3Xj8LOM9TPzBUgQG97tstChmso2C1LavF L+djgKVfthmaDzkyP1Yfp8nm3ltQvYnCgMTM8/nWCmu3Iak5uptVyBiO6dQnsaMnGck8 bd54bfxN1yzYrLW3Chy4hULJMuTfQUShSy2NuBLm1bIhzV6p9k+dynhyV/wt8s4D56YD 6iwX258MaYUL4eOg+tW4h99FQ9dlrTaz2WqMUlf54YNF2NVI9kFgiyERxvYr8pCeusbi nB/e8akfD9rvguQmhRMbRQWfYOFrrxl5Ely1VQNj6UzlDoq/IW1I/c0d/0k2XKAxd9Ml hdBw==
X-Gm-Message-State: AOUpUlEGoNofcHI8cnLaT7ZUcpo6GY70il4HlhARPb+4qrOrJTVpxSPh yzbL37Ldiz90t4ACsgg735/pRebddGVaFnE65m07q3Nz
X-Google-Smtp-Source: AAOMgpffFD8pektIHQu7rniJ094N3duFUeC5GRXxAATMN5oNTeee+NrRx9BxKA8Xo0VhDNkfmn+tNFcD1p8E3MxOscw=
X-Received: by 2002:aca:3d56:: with SMTP id k83-v6mr12545162oia.166.1533534946297; Sun, 05 Aug 2018 22:55:46 -0700 (PDT)
MIME-Version: 1.0
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 06 Aug 2018 15:55:36 +1000
Message-ID: <CABkgnnVFYMjWDk6zEEA8T_6qg+6qO9yAwVF70foMj4bXEdBaqQ@mail.gmail.com>
Subject: The first octet
To: quic@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/N2lbdSFFxkhAYtwCCBlNHBZeCEU>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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, 06 Aug 2018 05:55:49 -0000
It appears as though we're about to get some information about how deployable the QUIC invariants are. Ian tells me that Google are most of the way to deploying a protocol that uses QUIC invariants and should be able to confirm that this works by the interim. Well, either that or to be able to tell us what doesn't work, which I'm hoping isn't a problem we have to deal with. I'd like to spend some time at the interim on what we do with the type bits in the protocol. This email is an attempt to thoroughly cover the constraints that we have here and attempt to describe a process that I hope should get us to a conclusion shortly after Bangkok. Looking at open design issues, this cluster is the one that is the biggest threat to our schedule. Design Status and Constraints Long Header The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we have are currently allocated to the 4 types of long header packet, using only 252-255. All other values are currently unused. With respect to design constraints, there is only one that I'm aware of and that is a potential collision with RTP (and RTCP) on this octet (see RFC 7983), which use 0x10xxxxxx (128-191). The open question here is what we do with unused types. We might debate creating a registry for unused values. We might want to grease values. We could even decide to encrypt these values (though the design of Retry makes that more difficult, because the contents of that packet aren't encrypted at all). I'm not aware of any plans to use these bits, except perhaps what might be done to be consistent with the short header changes, so we might have some latitude here. Short Header The short header uses the 0b0xxxxxxx pattern (0-127). This is far more complex and we have a bunch of open questions that will make this difficult. Right now, we use the 0b0K110RRR as the pattern, with K being the key phase, and RRR being reserved for the spin bit experiment. Those fixed bits are (largely) temporary, and might be reclaimed once existing deployments of Google QUIC (pre-44) are phased out, so I think that we might want to reclaim some or all of them. There is a chance that the reserved bits will also become available (if not all, then maybe 2 of them). That will be decided in Bangkok, but we might want to have a plan for those bits. The constraints that I am then aware of are these: 1. RFC 7983 has the lower half of the first octet fairly densely populated for demux. Of the protocols there, my understanding of their relative importance puts STUN (0-4) as fairly critical, if not mandatory, then TLS (20-63) as optional. ZRTP (16-19) and TURN channels (64-79) are both apparently unimportant, though each might be opportunistically accommodated. 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits. I suggest that we allow for this, not counting on having any more bits than N-3, or assuming that only that many bits will be available. 3. Kazuho points out that the key phase is a linkability vector. We might want to consider encrypting that. We could do that by fixing the packet number key and not updating it after key updates and using more output from that process to mask the bit (and maybe other bits in this field). 4. I realize that we don't have to put a key phase in every packet if we are less concerned about being able to update immediately. If we adopt a scheme to what was proposed in DTLS, then a longer encoding can be used during the preparation and signaling phase. I'll follow up with another email on this subject. One thing that we could use extra bits for is to move the packet number size back into this octet. We could even move packet number bits back, depending on available space. That might make some difference to the number of bytes we allocate for packet numbers. Process Given that we don't have answers to some questions we might conclude several ways. I proposed that we agree on principles, starting with: 0. (This should already be agreed, but I'm repeating it because it's important.) The low 7 bits of the first octet are version-specific and can change in the next version of the protocol. A. What do we want to do with unused bits? Do we want to ensure that they are always used? Or can they be reserved? If so, how would they be reserved (fixed values, random values, greasing, etc...)? B. Should things in the first octet be encrypted where possible (for example, using an extension of packet number encoding). C. Should packet number encodings should be consistent between long and short header forms? D. What should we do with key phase? This was an open issue from the stream 0 design team, which might alter the outcome here. I have another email that covers this in more detail. E. How should we accommodate multiplexing? For me, the big questions here are whether we allow for RTP to collide with the long header and which of the protocols we privilege by avoiding with the short header. My hope is that reaching conclusion on those principles should allow us to to agree on designs that allow for 0, 1, or 3 bits of spin bit. That way we know what to do with the outcome of the discussions we plan to have in Bangkok and can implement the changes relatively quickly. For those who read this far, if you have opinions on what principles should drive this design, please respond here. If you have a proposed design (or designs) and can explain the principles that are expressed, that's OK too. If this gets enough feedback, I might arrange a call for interested parties. I don't expect that we'll reach a conclusion before the interim, but I don't think that we can let this go unresolved much beyond that point.
- The first octet Martin Thomson
- Re: The first octet Dirkjan Ochtman
- Re: The first octet Martin Thomson
- Re: The first octet Christian Huitema
- Re: The first octet Christian Huitema
- Re: The first octet Jana Iyengar
- RE: The first octet Mike Bishop
- Re: The first octet Mikkel Fahnøe Jørgensen
- Re: The first octet Kazuho Oku
- Re: The first octet Martin Thomson
- Re: The first octet Kazuho Oku
- Re: The first octet alexandre.ferrieux
- Re: The first octet Colin Perkins
- Re: The first octet Martin Thomson
- Re: The first octet Martin Thomson
- Re: The first octet alexandre.ferrieux
- Re: The first octet Ian Swett
- RE: The first octet Roni Even (A)
- Re: The first octet alexandre.ferrieux
- RE: The first octet Roni Even (A)
- Re: The first octet Ian Swett
- RE: The first octet Roni Even (A)
- Re: The first octet Kazuho Oku
- Re: The first octet Brian Trammell (IETF)