RE: Final DATA frames

The interop issue is that a proxy might inspect the headers, see no indication of trailers, use a len=0 DATA frame, then arrive at the end of the origin’s response and discover trailers there anyway that it now can’t send.  As you say, the proxy can be cautious, and proxies are also allowed to discard trailers, so it’s not a hard interop failure.  But it’s an unfortunate corner-case in an otherwise beneficial change.

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Sent: Friday, December 7, 2018 4:06 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

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<mailto: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<mailto:lucaspardue.24.7@gmail.com>>
Sent: Friday, December 7, 2018 3:39 PM
To: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>
Cc: Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>; Ryan Hamilton <rch=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>>; Jana Iyengar <jri.ietf@gmail.com<mailto:jri.ietf@gmail.com>>; IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; HTTP Working Group <ietf-http-wg@w3.org<mailto: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<mailto: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<mailto:fenix@fb.com>>
Sent: Friday, December 7, 2018 1:27 PM
To: Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>>; Ryan Hamilton <rch=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>>
Cc: Jana Iyengar <jri.ietf@gmail.com<mailto:jri.ietf@gmail.com>>; IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; HTTP Working Group <ietf-http-wg@w3.org<mailto: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<mailto:lucaspardue.24.7@gmail.com>>
Date: Friday, December 7, 2018 at 12:23 PM
To: Ryan Hamilton <rch=40google.com@dmarc.ietf.org<mailto:rch=40google.com@dmarc.ietf.org>>
Cc: Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>, Jana Iyengar <jri.ietf@gmail.com<mailto:jri.ietf@gmail.com>>, IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>, Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>, HTTP Working Group <ietf-http-wg@w3.org<mailto: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<mailto:40google.com@dmarc.ietf.org> wrote:
On Fri, Dec 7, 2018 at 10:16 AM Roberto Peon <fenix@fb.com<mailto: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.