Hello Marten,
Thank you for your feedback and questions. Answer inline:
Le 16/09/24 à 15:40, Marten Seemann a écrit :
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?
Yes. This is the first "critical" remark on the arxiv paper, page 5. It
apparently got some bad copypasta, but it should read:
"If the position of elements within the encrypted layout is predictable
by the receiver, then only applying the second principle is required,
and we can process from left to right. A protocol making this assumption
constrains its extensibility to predictable formats."
Note that for QUIC, we could relax further the principle, and only move
the type field to the end of each frame. But, this is actually a change
that, I think, would require further implementation efforts. The nice
thing of reversing the whole format of each stream frame is that the
processing order is unchanged compared from QUIC v1 because we now
process control information from *right to left *instead of the usual
buffer offset moving from left to right. As a result, the code needed to
read and process the new wire format should be the same as in QUIC v1.
The efficiency gain would then come from leveraging the hidden copy
within the AEAD decryption to perform Stream data reassembly during
decryption. Two steps in one, essentially.
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?
It might be using incorrect naming, but it is indeed as you say: we mint
a new QUIC version. We reserved 0x00791097 using Martin Thomson's
Codpoint picker (https://martinthomson.github.io/quic-pick/).
Note that I am not sure to see how it contradicts the stated goals? The
other option would be to only move the Type to the end, but it does not
work for the Ack frame (this one needs to be reversed due to the
relative order of elements that must be preserved). Furthermore, not
reversing the elements means that this is the parser code that needs to
be reversed, and that seemed to be against the stated goal, so I didn't
go with this option.
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.
It is not my intention to mandate a single Stream frame per packet
(Draft, Section 8). We can multiplex, but we only gain contiguous
zero-copy for the first Stream frame within a packet, and the others
will require a copy. My intention is to recommend 1 Stream frame per
packet. I think this is already what quiche does by default, and Google
QUIC too.
I think you have an important point. The intention is to really have low
changes to packetization logic. We only have a few hundred lines in
quiche to apply the proposal, which, I think, supports the "low" statement.
I'm not sure I fully understand the proposed changes to the
retransmission logic either.
Does Section 5.2.2 of the paper help? The main idea is to drop spurious
retransmissions before AEAD decryption. To avoid any other loss, it is
suggested to avoid adding control or other stream frames within a packet
holding re-transmitted frames.
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.
I'll open an issue to clarify. The intention is only to restrict to 2^30
opened streams. The total total number is still 2^62. I think if it is
an issue, this can be reworked.
* 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.
Mmh. I am not sure to follow how corruption could happen. I'll open an
issue on the draft's github to track this.
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"?
In my mind, "quic" refers to the header, and "he" to a frame that the
proposal reverse to "eh". I might also have chosen this one because we
can pronounce it :-p
Thank you for your help,
Florentin
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
<https://www.ietf.org/archive/id/draft-frochet-quicwg-reverso-for-quic-00.html>
[1] https://github.com/frochet/draft-rochet-reverso-for-quic
<https://github.com/frochet/draft-rochet-reverso-for-quic>
[2] https://github.com/frochet/quiceh
<https://github.com/frochet/quiceh>
[3] https://reverso.info.unamur.be/
[4] https://arxiv.org/abs/2409.07138
<https://arxiv.org/abs/2409.07138>
