Re: Final DATA frames

TLDR: If the focus is on shipping v1 and making sure we don't introduce
premature optimizations into HTTP/3, I thInk we should seriously consider
moving PUSH and the existing priorities to an extension.

It's too late on this issue, but I was going to add that this is very
useful for the CONNECT case.  Other comments below.

On Tue, Dec 11, 2018 at 12:46 PM Roberto Peon <fenix@fb.com> wrote:

> Yeah, I’m aware, having helped to write at least some of them with you and
> others here as partners!
>
> It isn’t like I hate optimization-- I’m just really scared of having to
> deal with this gone wrong. History has proven it is very likely that
> someone won’t get this right, and then protocol features will stop working,
> and pain will ensue, and the protocol will be less useful.
>

Why won't they get THIS right?  Your example below of PUSH_PROMISE is not
convincing, given the one proxy I am familiar with puts all PUSH_PROMISEs
before the response.


> If we could put the header/payload into separate streams, then that’d be a
> step forward along a path to enabling such optimization (and compatible
> with the additional changes you’d need to handle PP)
>
> … but I don’t want to think about that for V1.
>

I'll note this is strictly more complex to implement.


>
> I’d rather get what we have now done, and look at further optimizations in
> a V2 that we get out the door after a very short time window.
> -=R
>

This issue is/was not blocking us getting QUIC V1 done, particularly the
HTTP draft.  There are things we could simplify that would help the HTTP
draft along, such as moving priorities and PUSH to extensions.


>
> *From: *Ryan Hamilton <rch@google.com>
> *Date: *Monday, December 10, 2018 at 5:56 PM
> *To: *Roberto Peon <fenix@fb.com>
> *Cc: *Martin Thomson <martin.thomson@gmail.com>, Mike Bishop <
> mbishop@evequefou.be>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>,
> Kazuho Oku <kazuhooku@gmail.com>, Jana Iyengar <jri.ietf@gmail.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
>
>
>
> 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.
>
>