On 3/18/2021 10:42 AM, Lucas Pardue wrote:
Hey Matt,
On Thu, Mar 18, 2021 at 3:06 PM Matt Joras <[email protected]> wrote:
I think what Lucas is suggesting, and has been suggested before, is
that we are likely to have many frames which have similar
transmission/loss/transport handling properties, so why not have a
generic frame we build atop for some extensions?
I would hope we don't take this direction, as we did not take this
direction in the "core" frames in the specification, many of which
have identical transport handling. The design of QUIC v1, IMO,
encourages more frames rather than fewer. It is very easy for us to
add new frames. Putting "similar" frames all on a generic frame's
framework doesn't really save us time in specifying the semantics of
that frame. At best it might save some implementation complexity, but
I would argue that such concerns can be addressed by the
implementations. For example, mvfst has the notion of a generic
"simple frame" which is one which is not retransmitted and there are
not expected to be a great many of them. Many extension frames will
likely be implemented using this implementation-specific framework,
and I would expect other implementations to have their own techniques
for optimizing the implementation of new frames. And as Christian
notes an implementation will always have to implement the semantics of
what the frame actually does anyway.
You've done a much better job of articulating the idea that I had.
My suggestion was motivated by an observation that people designing
extensions might have to revisit the same questions over and over: "does
this frame need to be ack-eliciting, can a packet of pure frames be sent,
does the frame behave like that one or this one, or does it need to be a
little special". This is all in the context of how the frame affects the
transport, not the how the frame enables the extension. We're a young WG,
and there are not many design patterns or cookie-cutter examples to help
people focus on the problem they are solving rather than getting bogged
down by problems they might cause. There is institutional knowledge in the
WG and I'd love for us to find a way of capturing that so that others can
benefit. The mvfst example sounds great, you optimized for implementers. A
concrete frame type might be too far. But maybe we could start thinking
about some format to build upon the advice already in the 19.21 of the
transport doc. That might come with time as we learn but maybe some people
already have some ideas...
Cheers
Lucas
[1] https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-19.21
I suppose that you mean the part that says "Extension frames MUST be
congestion controlled and MUST cause an ACK frame to be sent. The
exception is extension frames that replace or supplement the ACK frame.
Extension frames are not included in flow control unless specified in
the extension." The TIMESTAMP frame falls in this "supplement the ACK
frame" category.
What we have now is simple: just explain in the spec that the extension
is treated as an extension of the ACK. I am not sure that we know enough
to specify a container format or any such superstructure. Consider for
example the ACK_MP proposals, in which a single packet could carry
several ACK_MP. There are good reasons to add a TIMESTAMP to such
packets, but you need only one of those for several ACK_MP. It would be
very easy to define "container" formats that break in such unanticipated
cases.
-- Christian Huitema
