On Tue, 14 Jun 2022 13:54:07 -0700, Christian Huitema wrote:
> On 6/13/2022 7:03 AM, Michael Eriksson wrote:
> > [...]
> >
> > Acknowledgements
> >
> > The current version of the multipath draft specifies the use of
> > ACK_MP frames when multipath has been enabled. I suggest that the
> > regular ACK frames should be used also for multipath, and that
> > ACK_MP frames could be optionally used as an optimization.
> >
> > The ACK frame would mean that packets on this particular path is
> > acknowledged. The implementation would be very similar to
> > singlepath QUIC when it comes to RTT estimates, loss detection
> > etc, which would reduce the implementation complexity.
> >
> > ACK_MP, on the other hand, could be used to acknowledge packets
> > received on other paths (it could be used for the same path but
> > with some overhead compared to a regular ACK frame). Some reasons
> > to use ACK_MP:
> >
> > * Faster acknowledgement can allow some congestion control
> > algorithms to increase the congestion window (but see below)
> >
> > * Faster loss detection (and retransmission) in some cases
> >
> > * Reduced buffering on the sender side and smaller flow control
> > receive windows
>
> Mixing ACK and ACK MP looks like a recipe for bugs in
> implementations. The current spec is very clear: implementations
> MUST use ACK-MP if they negotiate multipath. If they receive a
> regular ACK frame, they MUST treat it as an ACK for path 0.
Mixing ACK and ACK_MP is not a problem since it's not very different
from sending ACK_MP frames on both the same and other paths, and the
stack must already be able to handle ACK frames for singlepath QUIC.
A simple implementation can chose not to send ACK_MP frames at all.
Sending acknowledgments on the same path is already implemented for
singlepath QUIC and can be trivially reused for multipath QUIC. All
compliant implementations would have to handle received ACK_MP frames.
> From an implementation point of view, it is just as simple to send
> ACK "on this path" and ACK-MP "on this path."
This is not a big thing, but I think it's obviously better to keep
using the ACK frame for acknowledgements on the same path:
* Less changes from regular singlepath QUIC, both in specification
and implementation
* Less overhead (no need to send the path ID)
> > RTT updates and indirectly setting PTO timers should normally only
> > be done using in-path acknowledgements. Cross-path is interesting,
> > but maybe complex enough to warrant a Ph.D. thesis, especially
> > when path properties and existence change :-).
>
> There are many scenarios mixing one high bandwidth -- high latency
> path, and another low bandwidth low latency path. In these scenarios
> it is much more efficient to send the acknowledgements on the low
> latency path, and trigger retransmissions or at least probes based
> on that. If an implementation wants to support these scenarios, it
> has to manage the corresponding complexity.
Yes, and that is why I think that ACK_MP is useful. But as I wrote, I
don't think it is trivial to do, e.g., RTT estimation and loss
detection, particularly in dynamic cases when high priority traffic
also needs to be scheduled. That is why it would be nice to allow
simpler implementations to just reuse the already implemented in-path
acknowledgments.
> > Explicit path setup
> >
> > This is a half-baked idea, but maybe it's better to use new
> > signaling for setting up paths for multipath QUIC and not reuse
> > path validation (PATH_CHALLENGE and PATH_RESPONSE frames). That
> > could for instance give the server a chance to refuse another path
> > even if the client has enough connection IDs to create one.
>
> That would break the design goal of keeping exactly the same probe
> mechanisms as RFC 9000.
Where is that (and other) design goals documented?
Reusing the path validation is OK for me, but I think that in a longer
run it may be useful to do explicit signaling when setting up new
paths for multipath QUIC; I guess time will tell...
To be clear, the path validation *functionality* should be kept as is
also for path setup, but with new path setup *frames* (which would
include the path validation parameters) path information could be
negotiated.
/me
