Discussion: Remove ACK_MP frame from draft-ietf-quic-multipath ？

[iyangsj]

Briefly, the argument is as follows：

• The ACP_MP frame is not essential for multipath transport.
• Adding ACK_MP raises several design and implementation issues that need to be more thoroughly investigated.

Perhaps a better approach would be to follow the KISS principle：

• Use the ACK frame to acknowledge the received packets, which should be sent on the same path（Similar to the MPTCP).
• However, we do not prevent future extensions from defining ACK_MP, and using it requires negotiation.

[LPardue]

Seems like a dupe of #181, which was closed. Have you got any additional points that were not already addressed there?

[iyangsj]

@LPardue Thank you for such helpful information.
It is challenging to achieve a simpler and more elegant solution without making some trade-offs on requirements and suitable changes to conceptual models.
I would like to provide a detailed description later.

[LPardue]

Got it. To be clear, since #181 is now resolved it reflects the established consensus of the group. Therefore, the bar to reconsidering that consensus and making any changes is going to be higher. We'd be looking for convincing new arguments in a timely manner in order to revisit this matter.

[iyangsj]

The conceptual models of both QUIC and MPQUIC connections are similar because NAT rebinding occurs in both cases (as illustrated in the figure below). However, a QUIC connection is a simplified version of an MPQUIC connection, as it consists of only one master path, whereas an MPQUIC connection can include one or more master paths.

(Note: The Initial/Handshake packet number spaces, which are discarded after the handshake is complete, have been omitted for clarity.)

The multipath mechanism is mostly consistent with the draft-ietf-quic-multipath, but some differences are emphasized as follows:

• The master path and its slave paths in a QUIC/MPQUIC connection are collectively referred to as XPATH. In other words, an XPATH consists of multiple paths, but only one of them is used for transmitting non-probing packets. The simultaneous transmission of non-probing frames on multiple XPATHs is allowed in an MPQUIC connection.
• Require the use of non-zero Connection IDs in both directions. An endpoint MUST use different Connection IDs on different XPATHs. If the 4-tuple changes without the use of a new connection ID (e.g. due to a NAT rebinding), this is considered as a migration event.
• Use the ACK frame to acknowledge the received packets, which should be sent on the same XPATH. However, we do not prevent future extensions from defining ACK_MP, and using it requires negotiation.

Advantages of the proposed approach:

• It is easy to understand and implement.
• It avoids introducing unnecessary problems, such as ACK ambiguity, RTT estimation, large deviation with QUIC, etc.
• It does not prevent future extensions from defining ACK_MP for further improvement.
  • The usage of ACK_MP may not be necessary in all scenarios where the ACK frame is used, such as packet acknowledgment, loss detection, reception history updating, RTT estimation, and various algorithms that rely on ACK.

[mirjak]

In issue #181 it was already decided that it is better to be explicit and use ACK_MP. This also enables sending ACK over different paths which is seem as a feature, e.g. always using the lowest latency path. I don't see any new issue or concern raised here. Therefore I propose to close this issue with no action.

[iyangsj]

In issue #181 it was already decided that it is better to be explicit and use ACK_MP. This also enables sending ACK over different paths which is seem as a feature, e.g. always using the lowest latency path.

The existing design choice for ACK_MP is rooted in the per-path-per-pns model. Under this model, it seems there's no better design than what we currently have.

I don't see any new issue or concern raised here.

The present solution introduces unnecessary issues, such as ACK ambiguity, RTT estimation, large deviation from QUIC. Even worse, some algorithms that rely on ACK from the same path might not perform well.

If we properly design the conceptual model, we can find a simpler and more feasible design that avoids these extra problems.

[iyangsj]

CASE A:

• The Sender uses the BBR algorithm for both path A and path B.
• The Receiver replies ACK frames only on path A.

The simplest implementation is to compute smoothedRTT and RTTvar per Section 5.3 of [QUIC-RECOVERY] regardless of the path through which MP_ACKs are received. This algorithm will provide good results, except if the set of paths changes and the ACK_MP sender revisits its sending preferences.

• If the BBR B computes smoothedRTT regardless of the path through which MP_ACKs are received, it will underestimate the RTT and send data at a lower rate.

[iyangsj]

CASE B:

• The Sender uses the COPA algorithm for both path A and path B.
• The Receiver replies ACK frames only on path A.

The simplest implementation is to compute smoothedRTT and RTTvar per Section 5.3 of [QUIC-RECOVERY] regardless of the path through which MP_ACKs are received. This algorithm will provide good results, except if the set of paths changes and the ACK_MP sender revisits its sending preferences.

• When path A is congested, COPA B may inaccurately estimate the queueing delay for path B and improperly decrease the sending rate.

[mirjak]

Consideration for ACK scheduling and impact on congestion control is discussed in 6.3. Computing Path RTT. Further issue #77 notes that it might be useful for a future extension to provide guidance on ACK scheduling (frequency as well as which path to use). However, it was decided that this can be left as an extension. Therefore I'm closing this issue now. Thanks for the detailed discussion!