RE: Final DATA frames

Based on the discussion, it sounds like we at least don’t have consensus to include this particular solution in the HTTP/3 draft.  I’ve reverted the change for the time being; if we get consensus on this or a different solution, I’m happy to re-add whatever we agree on.

I’d also encourage people on the list to monitor the GitHub issue e-mail, etc. and drop in to comment on issues that they don’t want addressed.  The fact that there was an apparent gap in consensus between the mailing list and the GitHub discussion in a working group that uses GitHub so heavily is… troubling.

From: Roberto Peon <fenix@fb.com>
Sent: Tuesday, December 11, 2018 9:43 AM
To: Ryan Hamilton <rch@google.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

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.

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’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

From: Ryan Hamilton <rch@google.com<mailto:rch@google.com>>
Date: Monday, December 10, 2018 at 5:56 PM
To: Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>
Cc: Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>, Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>, Dmitri Tikhonov <dtikhonov@litespeedtech.com<mailto:dtikhonov@litespeedtech.com>>, Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>>, Jana Iyengar <jri.ietf@gmail.com<mailto:jri.ietf@gmail.com>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>, Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>>, IETF QUIC WG <quic@ietf.org<mailto: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<mailto: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<mailto:rch@google.com>>
Date: Monday, December 10, 2018 at 5:35 PM
To: Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
Cc: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>, Dmitri Tikhonov <dtikhonov@litespeedtech.com<mailto:dtikhonov@litespeedtech.com>>, Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>>, Jana Iyengar <jri.ietf@gmail.com<mailto:jri.ietf@gmail.com>>, Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>, Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>>, IETF QUIC WG <quic@ietf.org<mailto: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<mailto: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.