Re: Payload length 0

[Dmitri Tikhonov <[e-mail]>]

I agree with Martin and Ian.  We should keep the payload length field
and its value should be the actual length of the payload.

In addition to being simple, this allows some flexibility when packet
generattion is far away (in time or code) from actually sending a
packet.  That is to say, it is easier not to have to make the decision
which version of the payload length value to use when the packet is
created.

  - Dmitri.

On Fri, May 18, 2018 at 08:06:01AM -0400, Ian Swett wrote:
> I would also prefer to not do either of these, because I think it adds
> complexity and the byte savings are tiny.
> 
> On Fri, May 18, 2018 at 1:34 AM Martin Thomson <[e-mail]>
> wrote:
> 
> > Having just implemented this (and gotten it wrong once), I don't want more
> > special cases.  Both of these options need extra code.  As Kazuho points
> > out, filling in a two octet length is trivial.
> >
> > It's true that a length of 0 is invalid, but so is 1 through 16.
> >
> > Yes, this saves an octet, on about 4 packets per connection in the common
> > case, more like 2 if you actually take advantage of compound packets.
> > On Fri, May 18, 2018 at 3:08 PM Marten Seemann <[e-mail]>
> > wrote:
> >
> > > Jana asked me to raise this issue on the list, after we already had a bit
> > of discussion in https://github.com/quicwg/base-drafts/pull/1301.
> >
> > > The proposal is to make a payload length of 0 a special value, indicating
> > that the packet is not a coalesced packet, i.e. that the whole payload of
> > the UDP packet is the QUIC packet. This would eliminate an invalid value of
> > the payload length (there are no empty packets), save one byte for packet
> > lengths where varint encoding would result in a two byte number, and
> > apparently also simplify (some) implementations.
> >
> > > Kazuho argued creating two versions of each Long Header type (one with
> > and one without a payload length) is the better solution, since all values
> > below the AEAD tag length + 1 are invalid values anyway, and it would save
> > one more byte.
> >
> > > We should make a decision if and what we want to do about this.
> >
> >