Subject: [quicwg/base-drafts] f2f811: Transport integer encoding proposal

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Oct 2017 04:04:03 -0700

Branch: refs/heads/integers
  Home:   https://github.com/quicwg/base-drafts
  Commit: f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4
      https://github.com/quicwg/base-drafts/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4
  Author: Martin Thomson <[email-masked]>
  Date:   2017-10-13 (Fri, 13 Oct 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Transport integer encoding proposal

This proposal replaces all integer encodings in frames with a unified
variable-length encoding format.  It simplifies the encoding considerably, most
noticeably in the ACK frame, which I have largely rewritten.

This change increases the number of streams to 2^62, but reduces the number of
packets and octets per stream to that same number.  Both are very large values
anyway.  I kept the 2^10 scaling on the connection-level flow control window,
so that goes to 2^72 now.

The cost for ACK is a negligible decrease in efficiency for larger gaps or
ACK blocks (mainly between 64 and 255 in length).  This is counteracted by an
increase in efficiency if there are occasional ranges or gaps larger than 255,
which were previously very difficult to encode correctly.

As previously discussed, the timestamp format is removed.  In its place, we use
the same integer encoding, but with a scaling value, or exponent, that is
signaled in transport parameters, that should allow common ACK delays to be
expressed in fewer octets (an exponent of 0 only allows for 16ms to be encoded
in two octets, but the default exponent is 8, allowing up to 128ms of ACK delay
to be encoded on two octets with an 8us resolution).

I haven't made any changes for HTTP yet, I plan to do that in a separate PR.