Re: QUIC on streams compared to Minion (was 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,

On Sun, 18 Feb 2024, 10:23 Michael Welzl, <[e-mail]> wrote:

> Hi,
>
> Below:
>
> On Feb 17, 2024, at 5:40 PM, Lucas Pardue <[e-mail]>
> wrote:
>
> Hi Michael,
>
> On Sat, Feb 17, 2024, at 11:30, Michael Welzl wrote:
>
> Hi,
>
> QUIC over TCP… I hope that the people doing this are aware of the old work
> on Minion?   If not, see:
> https://datatracker.ietf.org/doc/html/draft-iyengar-minion-protocol-02
> https://datatracker.ietf.org/doc/html/draft-iyengar-minion-concept-02
>
> https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/nowlan
>
> IIRC, the original Minion idea was to introduce a marker in the
> bytestream, but the later development (perhaps captured in the drafts
> above?) worked off the principle that protocols above TCP already have
> these kinds of markers anyway - i.e., it doesn’t even need a change to the
> wire protocol, it’s just a “vertical” change about how to talk to the TCP
> buffer below.
>
> Considering this, it seems almost silly to me to ignore this and map QUIC
> over TCP when streams can so nicely be implemented via TCP too, just by
> “breaking” the TCP API “contract".
>
> My apologies if this is already a part of the plan - I just wanted to
> point out this work because at this point, it’s old and might have been
> forgotten - yet it seems to fit the idea of mapping QUIC over TCP like a
> glove.
>
>
> I'm aware of minion but haven't looked at it in a long while, thanks for
> the reminder. I read over it very briefly and I intend to spend more time
> digesting.
>
> However, my intial understanding is that minion has a hard requirement on
> DTLS, is that correct?
>
>
> I don’t know, it’s long since I last read the drafts.  But, in principle,
> the whole idea is based on being able to identify boundaries within the
> byte stream - and these boundaries must somehow be communicated
> (vertically) down to the TCP engine.  So, my suspicion is that they may
> have tied this to DTLS just for the convenience because DTLS does give you
> these boundaries.
>
> So, in principle, it’s not about DTLS, it’s about handing over boundaries.
> FWIW, in TAPS, this was solved with a “framer” concept, where a sort of
> callback for defining and parsing boundaries is handed over to the system.
> How to best do this in a more general and static system with TLS in
> between, I really don’t know.
>
>
> Part of the motivation of QUIC on streams, as pointed at in the draft, is
> to address a concrete problem in HTTP/2 stream limits. There are proposals
> for how to fix HTTP/2 itself but some of that effort could be invested in
> swapping over to HTTP/3 using QUIC on streams. Whether that would be
> successful depends on the change complexity matrix.
>
> It's the authors view that many clients and servers already support HTTP/2
> over TLS and HTTP/3 (native QUIC) simultaneously, meaning the complexity of
> adding HTTP/3 over QUIC over TLS is minimized. Mostly because QUIC
> implementations would need minor tweaks only. As an implementer (not author
> hat), the requirement to use DTLS would already start to be a put off for
> me in the above scenario.
>
> Can a minion-style (RE)COBS approach could be used with TLS? If so, what
> benefits would that bring over the current proposal?
>
>
> For the first question, see above: probably not easily, but technically,
> *somehow*, yes. For the second question: it would remove HOL blocking.
>
>
> HTTP/2 is already subject to TCP Head of Line Blocking. Maybe it could be
> nice to design a replacement that can fix that using TLS too.
>
>
> True!
>
>
> However, if I understand the minion protocol design (a big if, I'm happy
> to be corrected), it only supports 4 reorderings. Furthermore, since the
> "bookends" are in the plaintext stream, it seems trivial for an on-path
> attacker to interfere with them, opening up a new suite of security issues.
>
>
> Hm… I forgot these details.
>
> Well I don’t know if it *really* fits - it was just something that seemed
> suitable to me, as it might be able to remove HOL blocking when using
> streams, but … as always, the devil is in the details.
>

Yes, these are some interesting ideas, especially in the early phase of
discussion. Thanks for bring our attention (back) to minion!

Cheers
Lucas