Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt)

[Lucas Pardue <[e-mail]>]

Hi Matt,

On Sun, Feb 18, 2024, at 14:36, Matt Mathis wrote:
> What benefits would there be to http3 over TCP vs just downgrading?   I would bet that serializing http3 onto TCP forfeits (nearly) all of the benefits of http3.
From my perspective, the major benefit is for application implementers. I'll use HTTP as the example but the proposal is not limited to that.

Last summer, HTTP/2's stream concurrency model was abused to cause the largest layer 7 DDoS attacks recorded by several major operators. Mitigations and safeguards were put in place by affected implementations. More technical background is available from online sources, such as [1].

The realisations during that period was that HTTP/2's concurrency model a) doesn't protect anything when the remote peer can drive the stream lifecycle and continually renew its own credits and b) legitimate peers have a really hard time guessing what initial value of concurrency to use. In reality, the best chance a server has of ensuring interoperability and performance is to bound its minimum concurrency to 100. The blanket policy doesn't exercise the capability as it was intended. 

QUIC's stream concurrency model is slightly different, making it robust to this form of attack. Primarily because the endpoint controls things with explicit window increases via MAX_STREAMS frames. 

At IETF 118 a side meeting was held to discuss ideas for making HTTP/2 better. One proposal Martin Thomson and I wrote up was backporting QUIC's concurrency design [2]. 

QUIC on streams is the opposite of trying to piecemeal backport features to HTTP/2. A concrete benefit is that I could update my server to use HTTP/3 over Streams and have a more unified codebase where I can focus efforts in development, testing and hardening. Right now, efforts are duplicated and split between these two very similar variants.

I'm aware of greenfield projects that want to be QUIC first, and already just speak HTTP/3. Theyd like to increase accessibily by providing a TCP-based fallback thatvhas minimal complexity. They are a lot more enthusiastic about HTTP/3 over Streams than having to pick HTTP/2 client and server implementations and run through a whole new variant of implementation and testing.

Yes, there is HoL blocking. But that is livable. I'm aware of people very interested in running QUIC over unix domain sockets or equivalent. HoL doesn't matter there as long as the stream prioritaztion and frame scheduling can be suitably tuned.

> Fundamental issue: TCP has a 1 dimensional namespace for data (byte offset).   QUIC has a 3 dimensional namespace for data (channel, message sequence and byte offset).   There is no reversible mapping* from QUIC to TCP that preserves QUIC's native asynchrony.
> 
> * Except minion, which uses lots of kernel support to add a framing layer to break^H^H^H^H amend core TCP semantics.  Minion would be much harder to deploy than a lot of other options.
Yes I agree. I thought the I-Ds were pretty clear about this constraint. It might be nice to solve HoL blocking properly but I fear it would add more complexity, which would push the balance too far away from the ease of deployment we were targeting. 

Cheers
Lucas


[1] - https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack
[2] - https://datatracker.ietf.org/doc/draft-thomson-httpbis-h2-stream-limits/
> 
> On Sat, Feb 17, 2024 at 1:03 PM Hugo Landau <[e-mail]> wrote:
>> On Sat, Feb 17, 2024 at 08:39:18AM +0900, Kazuho Oku wrote:
>> > 2024年2月16日(金) 18:00 Hugo Landau <[e-mail]>:
>> > >
>> > > > Hello QUIC and HTTP enthusiasts,
>> > > >
>> > > > We, Lucas and I, have submitted two drafts aimed at broadening the reach of
>> > > > HTTP/3 - yes, making it available over TCP as well. We are eager to hear
>> > > > your thoughts on these:
>> > > >
>> > > > QUIC on Streams: A polyfill for operating QUIC on top of TCP.
>> > > > https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams
>> > > >
>> > > > HTTP/3 on Streams: How to run HTTP/3 unmodified over TCP, utilizing QUIC on
>> > > > Streams.
>> > > > https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-streams
>> > > >
>> > > > As the co-author of the two drafts, let me explain why we have submitted
>> > > > these.
>> > > >
>> > > > The rationale behind our proposal is the complexity of having two major
>> > > > HTTP versions (HTTP/2 and HTTP/3), both actively used and extended. This
>> > > > might not be the situation that we want to be in.
>> > > >
>> > > > HTTP/2 is showing its age. We discussed its challenges at the IETF 118 side
>> > > > meeting in Prague.
>> > > >
>> > > > Despite these challenges, we are still trying to extend HTTP/2, as seen
>> > > > with WebTransport. WebTransport extends both HTTP/3 and HTTP/2, but it does
>> > > > so differently for each, due to the inherent differences between the HTTP
>> > > > versions.
>> > > >
>> > > > Why are we doing this?
>> > > >
>> > > > Because HTTP/3 works only on QUIC. Given that UDP is not as universally
>> > > > accessible as TCP, we find ourselves in a position where we need to
>> > > > maintain and extend not only HTTP/3 but also HTTP/2 as a backstop protocol.
>> > > >
>> > > > This effort comes with its costs, which we have been attempting to manage.
>> > > >
>> > > > However, if we could create a polyfill for QUIC that operates on top of
>> > > > TCP, and then use it to run HTTP/3 over TCP, do we still need to invest in
>> > > > HTTP/2?
>> > > >
>> > > > Of course, HTTP/2 won’t disappear overnight.
>> > > >
>> > > > Yet, by making HTTP/3 more universally usable, we can at least stop
>> > > > extending HTTP/2.
>> > > >
>> > > > By focusing our new efforts solely on HTTP/3, we can conserve energy.
>> > > >
>> > > > By making HTTP/3 universally accessible, and by having new extensions
>> > > > solely to HTTP/3, we can expect a shift of traffic towards HTTP/3.
>> > > >
>> > > > This shift would reduce the necessity to modify our HTTP/2 stacks (we’d be
>> > > > less concerned about performance issues), and provide us with a better
>> > > > chance to phase out HTTP/2 sooner.
>> > > >
>> > > > Some might argue that implementing a polyfill of QUIC comes with its own
>> > > > set of costs. However, it is my understanding that many QUIC stacks already
>> > > > have the capability to read QUIC frames other than from QUIC packets,
>> > > > primarily for testing purposes. This suggests that the effort would be more
>> > > > about leveraging existing code paths rather than writing new code from
>> > > > scratch. Furthermore, a QUIC polyfill would extend its benefits beyond just
>> > > > HTTP, by aiding other application protocols that aim to be built on top of
>> > > > QUIC, providing them accessibility over TCP.
>> > > >
>> > > > Please let us know what you think. Best regards,
>> > > It's an interesting proposal. Looks fairly sensible.
>> > > I could see a lot of other uses also for having a mapping of the QUIC
>> > > application-level semantics without QUIC itself, such as for diagnostic
>> > > use or intra-DC backhaul of incoming traffic.
>> > >
>> > > I question the utility of implicit length signalling. Unless there's a
>> > > real use for this (maybe there is and I'm just not seeing it) I would
>> > > probably just prohibit these encodings. The max_frame_size transport
>> > > parameter proposed here cannot be reduced below 16384. So you're saving
>> > > at most 3 bytes (to encode 16384) for every 16384 bytes. That would seem
>> > > to yield an efficiency increase of 0.018%. For larger max_frame_size
>> > > values this obviously gets even smaller.
>> > >
>> > > Is there a rationale to supporting this I'm not seeing?
>> >
>> > Thank you for your comments!
>> >
>> > Regarding your question, in the initial draft, we attempted to limit
>> > changes to the way frames are communicated, while preserving the frame
>> > encoding of QUIC v1 unchanged. The purpose of this approach is to
>> > maximize code reuse between QUIC v1 and QUIC over Streams.
>> >
>> > For STREAM frames that lack length fields, we considered two options:
>> > a) defining a method to deduce the length from another source, or
>> > b) prohibiting the use of such frames.
>> >
>> > We opted for option (a) for consistency, under the assumption that it
>> > would not be more complex to implementations than (b).
>> >
>> > However, it was a narrow decision. I acknowledge that opting for (b)
>> > would also be straightforward to implement, especially since STREAM
>> > frames lacking length fields are identified by specific frame types
>> > (namely, 0x08, 0x09, 0x0c, 0x0d), and considering we're already
>> > restricting the use of certain QUIC v1 frames.
>> Yeah. I would strongly support (b) without a very clear motivating use
>> case otherwise.
> 
> 
> --
> Thanks,
> --MM--
> Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.