Re: Payload length 0

[Jana Iyengar <[e-mail]>]

I don't have a strong preference, but a weak one: It seems silly to have a
length field in non-coalesced packets, and non-coalesced packets will be
the common case.

There may be a slightly more compelling reason though. I've been thinking
about optimizing loss recovery for coalesced packets, and I keep running up
against the possibility that a future middlebox might split coalesced QUIC
packets, if it is allowed. I have been thinking about future-proofing
coalesced packets from getting split by such middleboxes (as they do for
TCP), and it occurs to me that a special value of 0 could be used as this
signal. If length is 0, then the packet is coalesced, and otherwise not.
This forces a middlebox to forward coalesced or non-coalesced packets as
they are, without any re-packetization shenanigans.

If folks agree that there's value in this signal, length of 0 may be a neat
way to get it.

On Fri, May 18, 2018 at 7:05 AM, Deval, Manasi <[e-mail]>
wrote:

> Agree with keeping payload length in the header.
>
>
> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of Dmitri Tikhonov
> Sent: Friday, May 18, 2018 6:44 AM
> To: Ian Swett <[e-mail]>
> Cc: Marten Seemann <[e-mail]>; IETF QUIC WG <[e-mail]>;
> Martin Thomson <[e-mail]>
> Subject: Re: Payload length 0
>
> 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.
> > >
> > >
>
>