Re: Final DATA frames

Hmm, an out of order delivery issue there. I was defending this design
rather than poking holes is. Regardless, the reason I like it is that it
has flexibility down to the per-request level. I understand concerns but
think a server actor can mitigate them by simply not supporting len=0. I
can't see the interop issue, but perhaps I'm just missing it.

Licas

On Sat, 8 Dec 2018, 00:01 Mike Bishop <mbishop@evequefou.be wrote:

> Not a blocker in my view, but it’s a fair critique that this design is
> mutually exclusive with those features.  A server (whether proxy or
> application library) that wants to retain the ability to do mid-content
> push or trailers can’t use this feature.  A server that is reasonably
> certain that it won’t need them could use this feature as an optimization.
> It’s worth noting that a “final DATA frame” is only ever that, and need not
> be used.
>
>
>
> I wasn’t planning to get into this yet, but since it’s relevant, I have an
> alternate design as an extension (not yet published) here
> <https://mikebishop.github.io/quic-external-data/draft-bishop-quic-external-data.html>.
> One option is to revert this change and interested parties can work on the
> extension instead, if there’s interest.
>
>
>
> *From:* Lucas Pardue <lucaspardue.24.7@gmail.com>
> *Sent:* Friday, December 7, 2018 3:39 PM
> *To:* Mike Bishop <mbishop@evequefou.be>
> *Cc:* Roberto Peon <fenix@fb.com>; Ryan Hamilton <rch=
> 40google.com@dmarc.ietf.org>; Jana Iyengar <jri.ietf@gmail.com>; IETF
> QUIC WG <quic@ietf.org>; HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Re: Final DATA frames
>
>
>
> Perhaps I'm overlooking a few things but the way I'd see it is that such a
> proxy could be conservative and chose never to use len=0 on responses that
> it is in control of.
>
>
>
> If it wanted to be more flexible at cost of risk, a proxy might also use
> the content-length header to make an informed decision. The header is not
> required, which sort of aligns with an origin generating a dynamic response
> of unknown total length.
>
>
>
> Wrt to push. A proxy could use reception of a link header, with preload,
> to decide to push before generating the parent request-response payload. If
> the upstream wants to support "pass through" of push promise properly,
> being conservative with length=0 would also be sensible.
>
>
>
> Trailers, well they are are hard I agree. Mike's provided some options but
> I'd ask exactly what trailers are applicable to H3. Is this design really a
> blocker to  use?
>
>
>
> On Fri, 7 Dec 2018, 22:50 Mike Bishop <mbishop@evequefou.be wrote:
>
> Trailers SHOULD be declared in the headers, but it’s true that a proxy
> whose origin violates that SHOULD could find itself in a state where it has
> to drop the trailers.
>
>
>
> *From:* Roberto Peon <fenix@fb.com>
> *Sent:* Friday, December 7, 2018 1:27 PM
> *To:* Lucas Pardue <lucaspardue.24.7@gmail.com>; Ryan Hamilton <rch=
> 40google.com@dmarc.ietf.org>
> *Cc:* Jana Iyengar <jri.ietf@gmail.com>; IETF QUIC WG <quic@ietf.org>;
> Mike Bishop <mbishop@evequefou.be>; HTTP Working Group <
> ietf-http-wg@w3.org>
> *Subject:* Re: Final DATA frames
>
>
>
> It will become very easy for an implementation which otherwise seems
> conforming to mess up and have no way of using push, or communicating
> trailers.
> This really seems like premature optimization, especially in the case
> where we’re taking options off the table already (like having the payload
> be separate).
>
> A little inefficiency seems much less scary than features no longer
> interoperating (e.g. because a proxy is very unlikely to know whether the
> response will have trailers, etc. without some very interesting
> coordination). That would feel very HTTP/1.1 pipelining (which was a good
> idea, but couldn’t effectively be implemented interoperably) to me. That
> was not at all a fun situation.
>
>
> This makes me feel very uneasy.
>
> -=R
>
>
>
> *From: *Lucas Pardue <lucaspardue.24.7@gmail.com>
> *Date: *Friday, December 7, 2018 at 12:23 PM
> *To: *Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
> *Cc: *Roberto Peon <fenix@fb.com>, Jana Iyengar <jri.ietf@gmail.com>,
> IETF QUIC WG <quic@ietf.org>, Mike Bishop <mbishop@evequefou.be>, HTTP
> Working Group <ietf-http-wg@w3.org>
> *Subject: *Re: Final DATA frames
>
>
>
> I was swayed by the discussion on this topic to support the proposal we
> ended up with. As Ryan puts it so well, we don't discount such other use
> cases, we just need the server to have enough information to decide how to
> respond on the initial DATA frame it responds with.
>
>
>
> And to that end, I think it has enough enpowerment. If risk averse, it
> would not use this optimisation. If sensitive to push or trailers, it can
> take the care to allow them.
>
>
>
> Lucas
>
>
>
> On Fri, 7 Dec 2018, 20:12 Ryan Hamilton <rch=40google.com@dmarc.ietf.org
> wrote:
>
> On Fri, Dec 7, 2018 at 10:16 AM Roberto Peon <fenix@fb.com> wrote:
>
> AFAICT, the github conversation didn’t touch on the interrelation of
> framing-on-stream and push-promise, or trailers.
>
>
> Given the current inline (interleaved) expression of push-promise within a
> stream, you don’t want to prevent yourself from being able to insert the
> push-promise description into the stream when you need to do it.
> It’d also make trailers “interesting”, i.e. likely prevent them from
> working properly.
>
> If having a zero-length frame is considered a problem, then another way to
> solve that would be to assert that the length of a frame is the stated size
> + 1, i.e. if that field is zero, then the length of the payload is one.
>
>
>
> Well, the motivation for the change is to avoid extra overhead in the very
> common case of an HTTP message with no trailers and no associated pushes
> (and dynamically generated content). If a particular HTTP message does not
> have those properties then it can easily use a non-zero length to terminate
> the DATA frame and follow it up with pushes or trailers.
>
>