RE: Final DATA frames

I'm personally hoping that the HTTP spec will change less frequently than the QUIC spec will, and that changes will be primarily via extensions.  But the choice I'd like to make on list right now is:

  *   Keep the change - it's an optimization for a common case, and proxies can disable it if they expect the uncommon case to apply
  *   Revert the change - the optimization isn't worth the possibility that proxies shoot themselves in the foot



Whether we can do better in an extension or by adding new transport features in v2 doesn't block either option - we can keep this change and still publish something better later.  My count of people on this thread so far is split about 50/50 between keeping the change in versus various reasons to reject it.



-----Original Message-----
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Sent: Sunday, December 9, 2018 1:27 PM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Mike Bishop <mbishop@evequefou.be>; Jana Iyengar <jri.ietf@gmail.com>; Roberto Peon <fenix@fb.com>; rch=40google.com@dmarc.ietf.org; HTTP Working Group <ietf-http-wg@w3.org>; lucaspardue.24.7@gmail.com; IETF QUIC WG <quic@ietf.org>
Subject: Re: Final DATA frames



On Sat, Dec 08, 2018 at 10:18:04AM +0900, Kazuho Oku wrote:

> Admittedly, the alternatives have less chance in making it to v1. But

> the question is, is always using length field so bad that we cannot

> wait for a more ideal fix?



I don't think it's so bad.  The overhead incurred by the DATA frames is small: 0.2% to 0.02% [1].  I think we can live with it for v1.



  - Dmitri.



1. https://github.com/quicwg/base-drafts/issues/1885#issuecomment-431348155