On 12/14/2020 10:44 AM, Yanmei Liu wrote:
> ACK_MP frame:
> If this is an extension to QUICv1 it makes sense (and this seems to be the case). If it is intended as a new protocol version, maybe replace the regular ACK frame to avoid protocol bloat? I can see the counter argument that a new frame ID makes it easier to reuse v1 im>
plementations, but protocol bloat is a concern as well.
I think that it’s important to keep compatible with QUIC-v1. If implementations
send ACK frame in multiple paths, it still need to be processed without errors.
Some more explanations of this ACK frames issue. Sending packets and
receiving acknowledgements forms a control loop, triggering actions like
loss correction or changes in congestion control parameters. When
implementing control loops, it is generally better to keep delays short.
This has a clear effect in management of multiple paths. The shortest
loops are obtained when the acknowledgements are sent on the shortest
available path, which may not always be the same path over which data
was sent. Since we use a separate number space for each path, supporting
shortest-path-acknowledgements requires adding a path identifier in the
ACK_MP.
Part of the problem there is that we end up with four frame type
identifiers for acknowledgements, depending on whether the path
identifier is present or not and whether the ECN counters are present or
not. If I had to change something, I would put the ECN counters in a
separate frame that could be composed with the ACK frame, just like time
stamps can be carried in a separate time stamp frame. That way, we would
end up with just three frame types for ACK, ACK_MP and ECN counters,
instead of four. But the ECN counter decision was done a couple years
ago, and it is too late to change it now.
-- Christian Huitema
