I'm not entirely sure I understand where the efficiency gains come from, or why it's necessary to reverse the wire encoding of every single QUIC frame. Could the same effect be achieved if the data field of the first STREAM frame of each packet were guaranteed to start at a predefined offset?
Reading through the draft, these seem to be pretty drastic changes to the QUIC protocol. To me, this doesn't appear to be a simple extension, but rather a complete redesign of the entire QUIC protocol, to the point where the resulting protocol bears little resemblance to RFC 9000. This isn't necessarily a bad thing, but it does contradict the goals stated in the Goals section. Why not just mint a new QUIC version? Let me elaborate on why I think that these are drastic changes to QUIC. Reversing the wire representation of frames is one thing, but adding a number of fields to the Short Header, and mandating that any packet can only carry a single STREAM frame, seems to be a much larger change, requiring non-trivial changes to the packetization logic. I'm not sure I fully understand the proposed changes to the retransmission logic either. Furthermore, the changes to the variable encoding for the fields of the STREAM frame impose new limitations on the kind of applications that can be run on top of this new protocol: - The total number of streams appears to be restricted to 2^30 (whereas RFC 9000's varint encoding allows for 2^62 streams). This might not be sufficient for certain applications. - The proposed offset derivation mechanism (which works similarly to QUIC's packet number derivation) can lead to a corruption of STREAM data. While it is acceptable to have an algorithm that occasionally produces false results for packet number derivation (since these packets will end up undecryptable and being dropped), it's not acceptable to risk data corruption under any circumstances, no matter how rare they might seem. On a less serious note, I'm surprised your implementation is called "quiceh". You're not reversing the H3 layer, but the QUIC layer, so shouldn't it be "ciuqhe"? On Mon, 16 Sept 2024 at 19:58, Florentin Rochet <florentin.roc...@unamur.be> wrote: > Dear all, > > I submitted a draft [0], [1] to discuss a potential extension to the > QUIC protocol. In a nutshell, this extension is a collection of light > changes to the QUIC wire format with the goal to enable implementers to > provide a contiguous zero-copy interface on the receive path to an > application embedding QUIC, which is not something we can do on QUIC v1 > using atomic authenticated encryption APIs. > > This suggestion may help with QUIC's efficiency concerns to some extend, > and should be cumulative to any future benefit brought by UDP IO > optimizations. > > We have an implementation of the suggestions forked from quiche, called > quiceh [2]. We also have a blogpost [3] summarizing the rational and > expected benefits, as well as a (draft) paper [4] with more details and > experiments. > > I would suggest reading [3] first, then jumping into [4] for any detail > of concern, and then eventually reading [0]. Please let me know if you > have any question or feedback. > > @QUIC chairs: if possible, I'd like to have a few minutes at the next > IETF meeting (121 in Dublin?) to discuss this proposal. > > Best regards, > > Florentin > > [0] > > https://www.ietf.org/archive/id/draft-frochet-quicwg-reverso-for-quic-00.html > > [1] https://github.com/frochet/draft-rochet-reverso-for-quic > > [2] https://github.com/frochet/quiceh > > [3] https://reverso.info.unamur.be/ > > [4] https://arxiv.org/abs/2409.07138 > >
