Re: Final DATA frames

This change is intended to fix a purported shortcoming in the
HTTP/3 framing mechanism.  The claim is that

  " DATA frame encoding is inefficient for long dynamically
  " generated bodies. [1]

As shown in this thread and elsewhere, the framing overhead is
small.  What is the definition of "inefficient" that is used to
make this claim?

  - Dmitri.

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

On Mon, Dec 10, 2018 at 05:55:58PM -0800, Ryan Hamilton wrote:
> Not all endpoints are proxies :) And some of those endpoint which are
> proxies are able to communicate with their backends in order to establish
> such knowledge. The endpoints I work with are both able to establish such
> knowledge, fwiw.
> 
> On Mon, Dec 10, 2018 at 5:47 PM Roberto Peon <fenix@fb.com> wrote:
> 
> > This simplicity of the design here is also a trap. Sure, the extension is
> > simple, but it also makes it simple to fail to interoperate!
> > To be clear, only those proxies which have established some prior
> > knowledge that there will be no PUSH_PROMISE can safely use this
> > optimization with the protocol as designed today.
> > -=R
> >
> >
> >
> > *From: *Ryan Hamilton <rch@google.com>
> > *Date: *Monday, December 10, 2018 at 5:35 PM
> > *To: *Martin Thomson <martin.thomson@gmail.com>
> > *Cc: *Mike Bishop <mbishop@evequefou.be>, Dmitri Tikhonov <
> > dtikhonov@litespeedtech.com>, Kazuho Oku <kazuhooku@gmail.com>, Jana
> > Iyengar <jri.ietf@gmail.com>, Roberto Peon <fenix@fb.com>, HTTP Working
> > Group <ietf-http-wg@w3.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>,
> > IETF QUIC WG <quic@ietf.org>
> > *Subject: *Re: Final DATA frames
> >
> >
> >
> > As you say, there's a valid use case here. There's nothing about this
> > particular design which would prevent any sort of "send the body on a
> > unidirectional stream" extension from being worked on or implemented. That
> > some future extension might (or might not) be a better solution to this use
> > case does not seem to me to be a terribly compelling argument for reverting
> > this, particularly given the simplicity of this design.
> >
> >
> >
> > (I'll also point out that delivering the body on a unidirectional stream
> > doesn't necessarily work will with server push, as the PUSH_PROMISE is
> > required to arrive before the reference to the promised resource. So if the
> > PUSH_PROMISE happens on the main stream and the body goes on a different
> > stream, that ordering is not guaranteed without some addition properties.)
> >
> >
> >
> > On Mon, Dec 10, 2018 at 4:19 PM Martin Thomson <martin.thomson@gmail.com>
> > wrote:
> >
> > 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.
> >
> >

Received on Tuesday, 11 December 2018 02:41:41 UTC