Re: Lifting HTTP/3 Features into Extensions

2018年12月13日(木) 7:04 Lucas Pardue <lucaspardue.24.7@gmail.com>:
>
>
> On Wed, 12 Dec 2018, 21:36 Kazuho Oku <kazuhooku@gmail.com wrote:
>>
>> 2018年12月13日(木) 6:12 David Schinazi <dschinazi.ietf@gmail.com>:
>> >
>> > I think there is value in moving some features to extensions. I don't see anything in the charter preventing us from moving specific work items to extensions, especially if we believe it'll accelerate us shipping v1, and allow experimentations that could produce a better prioritization scheme. From what I heard from people involved in the HTTP/2 standardization efforts, some things about prioritization and push could have been done differently, and most likely would have if they had been standardized as extensions. It would be great for us to gain this flexibility in HTTP/3. Moving trailers to an extension would allow us to remove the length from DATA.
>>
>> I am fine with making push an extension, because it's something that
>> we might not need from day one.
>>
>> OTOH, I think that priorities need to be kept in the core
>> specification, considering the fact that it is a must-have for the web
>> browser use-case (the use-case we care the most). IIUC, the lesson
>> learned from HTTP/2 is that we see bad performance (worse than HTTP/1)
>> when priorities are not handled correctly by the servers. Therefore,
>> priorities need to be standardized alongside the core specification,
>> and we need to be clear that the servers need to implement it.
>
>
> This is a good defense of the need to prioritise delivery in a multixed protocol. I think in practice that it's been hard to mandate servers behave in any way, and to observe that they do as asked.
>
> Through the lens of interop, is there any difference in me ignoring the contents of the PRIORITY frames in the server, or just ignoring them completely (akin to an unsupported extension).

Interop-wise, you'd be fine with ignoring PRIORITY frames. There would
also be use-cases that do not require the use of priorities.

> I agree performance is important but I don't if the UA is always right.

It is true that servers can prioritize the responses by themselves,
for example by consulting the content-type header field. But browsers
have better information, because they know *how* the resources are
used (e.g., is it an async javascript load? is the image hidden?).

Fortunately, most of the web browsers are sending well-designed H2
priorities. We need to let the trend continue in H3.

> Could we try to draw on the transport's approach to congestion control algorithm?

Maybe, if the editors have strong preference to split the documents.

My argument is that priorities need to be defined alongside H3, and
that H3 cannot ship (or go into interop in the wild) without
priorities. The opposition to splitting the document is based on that
and the assumption that it would be easier to specify one thing than
two. I want to see H3 with priorities done soon.

> > Defining priorities outside core specification would be an additional
> burden for us (defining one document is easier than defining two), and
> also raises the risk of people failing to recognize that the support
> for priorities is a MUST for the browser use-case.
>
> So continuing the above thinking, one approach could be to extract the text but keep it core (I.e. mandatory to implement for H3). This is similar to QPACK document. That could provide some of the proposed benefits.
>
>> I also oppose to moving trailers to extension, because it's a feature
>> of the core HTTP spec.
>
>
> I agree with Kazuho here.
>
> Lucas
>>
>>
>> >
>> > David
>> >
>> > On Wed, Dec 12, 2018 at 10:43 AM Mike Bishop <mbishop@evequefou.be> wrote:
>> >>
>> >> To preface, this is really a separate discussion, linked to this one only by what is effectively whataboutism.  We don’t have consensus to do this complicating thing that optimizes for a common case, so why did we achieve consensus to do those other complicated things that optimize for uncommon cases?  But that consensus was achieved in HTTP/2, and my personal reading of the charter leads me to believe we’re prohibited from wholesale removal of H2 features in HTTP/3; we try to keep the same general spirit unless things are fundamentally incompatible with running over QUIC.
>> >>
>> >>
>> >>
>> >> Moving everything post-DATA to a separate stream is a fairly dramatic change, and I’m having trouble seeing exactly how that would work.  And it suffers the same liability that it’s likely to be an under-exercised code path.
>> >>
>> >>
>> >>
>> >> Priority and push were both controversial pieces of H2 for various reasons.  Unlike in HTTP/2, they are more decoupled from the stream state model in HTTP/3, and either or both could easily could become an extension.  I find the argument more persuasive for priority than for push, because one could very reasonably choose to experiment with several independent priority schemes – the pseudo-7540-style we have now, the three-bit SPDY-style priorities, a varint fixed priority, the weighted-group, etc.
>> >>
>> >>
>> >>
>> >> From: Ian Swett <ianswett@google.com>
>> >> Sent: Wednesday, December 12, 2018 9:27 AM
>> >> To: ianswett=40google.com@dmarc.ietf.org; Roberto Peon <fenix@fb.com>; Ryan Hamilton <rch@google.com>; Jana Iyengar <jri.ietf@gmail.com>; Mike Bishop <mbishop@evequefou.be>; HTTP Working Group <ietf-http-wg@w3.org>; Lucas Pardue <lucaspardue.24.7@gmail.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>; Kazuho Oku <kazuhooku@gmail.com>
>> >> Subject: Re: Final DATA frames
>> >>
>> >>
>> >>
>> >> From a technical perspective, yes.  But from a goals/process perspective, I think they related.  We've spent a lot of time on very complex work in the QUIC WG, and I realize everyone has a different perspective, but I'm confused by the amount of pushback this got relative to all the work we have done to make PUSH and something approximating(since they're actually different) H2 priorities work on top of QUIC.
>> >>
>> >>
>> >>
>> >> If I remember correctly, your main argument against this framing change was that the existing DATA frame with a length becomes largely useless and might be under-exercised.  That makes me feel like we've over-optimized for the complex special cases and made a design error or two at least one step prior to this proposal.
>> >>
>> >>
>> >>
>> >> To make a specific and relevant suggestion, maybe DATA should never have a length and if we want features that most requests don't use(trailers/PUSH_PROMISE/etc) we should put them on a separate unidirectional stream?
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Dec 12, 2018 at 12:02 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
>> >>
>> >> But you would agree that these are completely different discussions?
>> >>
>> >> One is whether to modify HTTP/3 framing mechanism.  The other is
>> >> changing HTTP/3 feature set.
>> >>
>> >> My point is that it is unjustified to to say that since we have
>> >> decided not to change the framing mechanism we should consider
>> >> dropping prioritization and push promises.
>> >>
>> >> On Wed, Dec 12, 2018 at 11:38:09AM -0500, Ian Swett wrote:
>> >> > I don't want to derail this too much(probably too late for that), and no
>> >> > one has a PR anywhere close to landing, but I do think we should start
>> >> > thinking of these as potential extensions.  I disagree that they're
>> >> > HTTP/2's primary features, both due to lack of use and lack of measurable
>> >> > benefits years after standardization.  Push might actually benefit from
>> >> > being an extension, because then potential improvements(ie: cache-digest)
>> >> > could be integrated into the extension more quickly.
>> >> >
>> >> > On the other hand, QPACK is relatively complex but we have clearer
>> >> > demonstrations of it's benefit.
>> >> >
>> >> > On Wed, Dec 12, 2018 at 9:00 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
>> >> > wrote:
>> >> >
>> >> > > On Tue, Dec 11, 2018 at 09:02:01PM -0500, Ian Swett wrote:
>> >> > > > 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.
>> >> > >
>> >> > > The EOS DATA frame and HTTP prioritization and push promises are not
>> >> > > equivalent.  One is simply fiddling with the way data is framed and
>> >> > > is not visible to the application.  The others are HTTP/2's primary
>> >> > > features.
>> >> > >
>> >> > >   - Dmitri.
>> >> > >
>>
>>
>>
>> --
>> Kazuho Oku



-- 
Kazuho Oku

Received on Wednesday, 12 December 2018 22:37:57 UTC