Re: Final DATA frames

[Martin Thomson <[e-mail]>]

FWIW, there is a valid use case here, but I'm not happy with the
specific design.

For instance, an extension that used a unidirectional stream for the
body of a request might be a better option.

On that basis, I would revert the change.
On Tue, Dec 11, 2018 at 10:36 AM Mike Bishop <[e-mail]> wrote:
>
> 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 <[e-mail]>
> Sent: Sunday, December 9, 2018 1:27 PM
> To: Kazuho Oku <[e-mail]>
> Cc: Mike Bishop <[e-mail]>; Jana Iyengar <[e-mail]>; Roberto Peon <[e-mail]>; rch=[e-mail]; HTTP Working Group <[e-mail]>; [e-mail]; IETF QUIC WG <[e-mail]>
> 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