Re: obsrvtaion on packet numbers

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Wed, 13 September 2017 20:58 UTC

Date: Wed, 13 Sep 2017 16:58:17 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Cc: Martin Thomson <martin.thomson@gmail.com>, Roni Even <roni.even@huawei.com>, QUIC WG <quic@ietf.org>
Subject: Re: obsrvtaion on packet numbers
Message-ID: <20170913205816.GA18476@ubuntu-dmitri>
References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <CABkgnnUnwcqNnozUZERG5hnbbEOkB4Apsx6qrNMzvYNh5-aC+w@mail.gmail.com> <5ba17907-1be7-da2d-1e2f-ae62254f2b40@tik.ee.ethz.ch> <20170913135614.GB3857@ubuntu-dmitri>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170913135614.GB3857@ubuntu-dmitri>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FRlmclwQ_ChaGainXGejL8Q62Fs>
Precedence: list

On Wed, Sep 13, 2017 at 09:56:14AM -0400, Dmitri Tikhonov wrote:
>     1. Why are there packet number and byte offset limits?  In
>        other words, why are there limits on the duration of a
>        connection?
> 
>     2. How are particular limits chosen?

In 2012, Jim Roskind wrote in "QUIC: Design Document and Specification
Rationale" [1]:

  " Header: Packet Sequence Number
  " 
  " In addition to sequencing packets, watching for duplicates,
  " and communicating what packets are missing, this number is
  " a critical part of the encryption.  This number forms the
  " basis of the IV used to decrypt each packet.  As a result,
  " it must conceptually be large, as it must never repeat during
  " the lifetime of the connection.  That need forced this sequence
  " number to be conceptually large, around 2^64 (more packets than
  " any connection would dream of sending), but we usually don’t
  " need to provide all 8 bytes in each packet!

And

  " even though we expect to support very large file transfers, it
  " will be rare that a stream will convey data that uses many of
  " the current 64 bits of maximum offset!

It seems that the author of QUIC took the [pragmatic] position that
these limits will never be reached.  On the other hand, his goals
at the time were also more modest:

  " The two primary support motivations for this transport are to
  " better support SPDY, and to further coalesce traffic. SPDY
  " currently runs over TCP, but has encountered a few performance
  " limitations.
                  (Ibid.)

This document seems to be the origin of the current limits in the
IETF QUIC Draft.  Now that QUIC is not just a transport for SPDY
but a generic transport protocol, perhaps it is time for a
reassessment.

  - Dmitri.

1. https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview

obsrvtaion on packet numbers Roni Even
Re: obsrvtaion on packet numbers Martin Thomson
RE: obsrvtaion on packet numbers Roni Even
Re: obsrvtaion on packet numbers joel jaeggli
RE: obsrvtaion on packet numbers Roni Even
Re: obsrvtaion on packet numbers Jana Iyengar
Re: obsrvtaion on packet numbers Roberto Peon
Re: obsrvtaion on packet numbers Mikkel Fahnøe Jørgensen
RE: obsrvtaion on packet numbers Roni Even
Re: obsrvtaion on packet numbers Roberto Peon
Re: obsrvtaion on packet numbers Mikkel Fahnøe Jørgensen
Re: obsrvtaion on packet numbers Mirja Kühlewind
Re: obsrvtaion on packet numbers Dmitri Tikhonov
Re: obsrvtaion on packet numbers Dmitri Tikhonov