Re: Lifting HTTP/3 Features into Extensions

Anyone proposing moving features out to optional extensions would be 
well advised to look at the history of IMAP, and the interop nightmare 
that this approach causes.

I think we need to take a good long look and make things we need 
non-optional.  If something is truly optional then you have to be 
prepared for it to cause interop problems, and you get a chicken and egg 
problem, where client vendors won't add support for an option unless a 
server vendor does, and vice versa. Making a feature optional is a 
pretty good way to consign it to oblivion.


------ Original Message ------
From: "David Schinazi" <dschinazi.ietf@gmail.com>
To: "mbishop@evequefou.be" <mbishop@evequefou.be>
Cc: "Ian Swett" <ianswett@google.com>; 
"ianswett=40google.com@dmarc.ietf.org" 
<ianswett=40google.com@dmarc.ietf.org>; "fenix@fb.com" <fenix@fb.com>; 
"Ryan Hamilton" <rch@google.com>; "jri.ietf@gmail.com" 
<jri.ietf@gmail.com>; "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>; 
"Lucas Pardue" <lucaspardue.24.7@gmail.com>; "QUIC" <quic@ietf.org>; 
"Martin Thomson" <martin.thomson@gmail.com>; "kazuhooku@gmail.com" 
<kazuhooku@gmail.com>
Sent: 13/12/2018 10:12:39 AM
Subject: Re: Lifting HTTP/3 Features into Extensions

>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.
>
>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 
>><https://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0396.html>, 
>>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.
>>> > >
>>>