Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

[Christian Huitema <[e-mail]>]

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