sending ACK_MP for packets arriving on a path yet to be validated

[kazuho]

How is an endpoint supposed to send ACKs in response to packets arriving on paths that have not been validated yet?

When receiving a packet on a new path, the receiver cannot send an ACK_MP frame on the new path. This is because ACK_MP frame is not defined as a probing frame.

The receiver has to either:

• a) send ACK_MP on a different path that has been validated already, or
• b) withhold sending ACK_MP frames until the receiver completes validation the new path

Either approach has its own downsides. Option A is going to have negative impact on RTT estimates (see #190), option B will be a diversion from QUIC v1 and we need to write it down if such behavior is permissible. The other option (C) could be to state that ACK_MP frames are probing frames.

Do we have a preference on the strategy?

[huitema]

I think it is better to acknowledge sooner rather than hold on. The discussion on #190 suggest to "just send the ACK on the available path". The only caveat is the need to keep all paths alive, but challenges and responses do that.

[yfmascgy]

My opinion is to go with option A. Suppose that a not-yet-validated path will soon be validated. The negative impact on RTT is going to be limited and smoothed out when new RTT samples arrive.

[marten-seemann]

Why not just include the ACK_MP frame with the PATH_CHALLENGE frame?

RFC 9000 Section 8.2 allows including other frames:

An endpoint MAY include other frames with the PATH_CHALLENGE and PATH_RESPONSE frames used for path validation. In particular, an endpoint can include PADDING frames with a PATH_CHALLENGE frame for Path Maximum Transmission Unit Discovery (PMTUD)

Maybe we should make it explicit (and encourage) that this also includes ACK_MP frames here?

[kazuho]

@marten-seemann I think the answer depends on what people want to do.

If some endpoints prefer sending acknowledgements on the path the packets were received, then yes, it would make sense for such endpoints to bundle PATH_RESPONSE and ACK_MP. That would be easy to implement and give good RTT estimate throughout the lifetime of the path.

OTOH, I'm not sure if we want to encourage all endpoints to bundle PATH_RESPONSE and ACK_MP. There are cases where it makes sense to send acknowledgements on a path other than on which you receive packets. For example, when receiving a packet via a cellular network, it could make sense to send ACK_MP frames through Wifi, as the latter has lower latency in general. In such case, it would make sense to send all ACK_MP frames through Wifi rather than sending some through cellular as a bundle.

[marten-seemann]

Sending them on a different path seems fine too. I didn't mean to suggest to always send ACK_MP frames on the same path, I was just arguing that there's no situation where (b) would be the preferred option.

[yfmascgy]

@kazuho @marten-seemann @huitema It seems that we need to modify Fig. 2 in the current draft, right? Right now in fig2, in response to PATH_CHALLENGE frame, we bundle ACK_MP with PATH_RESPONSE in the returning packet and transmit that packet on the new path. But in the draft we also say "An endhost should not send non-probing frames on a path in "Validating" state, as it has no guarantee that packets will actually reach the peer."

[huitema]

Picoquic does bundle ACK_MP (or ACK) with path response, but it treats that as an "opportunistic ACK" which may or may no make it through. The packet ranges will be acknowledged again next time the ACK_MP can be sent on a validated path.

[kazuho]

My +1 goes to allow including ACK_MP frames in probing packets. But we cannot have the same rule for ACK frames, because QUIC v1 states that ACK is a non-probing frame and hence cannot be included in probing packets.

Therefore, my preference goes to:

• state that ACK_MP frames are probing frames (and hence can be included in probing packets), and
• to avoid confusion, forbid use of ACK frames in 1-RTT packets of multipath QUIC (see https://github.com/quicwg/multipath/issues/220).

[mirjak]

Given everybody likes and implemented the bundling, I created PR #239 with the following text:

An endhost SHOULD NOT send
non-probing frames on a path in "Validating" state, as it has no
guarantee that packets will actually reach the peer, with an exception
of the ACK_MP frame. An endhost MAY bundle the ACK_MP frame with the 
PATH_RESPONSE frame; in this case it is RECOMMANDED to consider
the acknowledgement information as opportunistic and repeat
the acknowledged pacjet ranges in the next ACK_MP frame.
Alternatively ACK_MP frames can be sent any other active path.

Rather than saying ACK_MP frames are probing frames which I'm not sure generally makes sense, I think it is better to be explicitly about this case. Do people think use of normative language makes sense here?

[kazuho]

Rather than saying ACK_MP frames are probing frames which I'm not sure generally makes sense, I think it is better to be explicitly about this case.

I am not sure if I appreciate that approach - having rules based on types of packets, then having exceptions is hard to maintain.

In case of quicly, we use a table that defines the properties of each frame and refer to them before / after calling the frame handlers. I would not be surprised if other stacks take the same approach. It is hard to handle exceptions when stacks are written that way, not to mention the difficulty of analyzing the prototol.

[yfmascgy]

My question is why not we send ACK_MP from a path that has already been validated. Is there any issue for doing that?

[kazuho]

@yfmascgy That's a fair point, though the sense of room in #190 seems to be that we think its up to the receiver to select the path to send acks, the only recommendation is that the selection is stable.

Under the premise that that is the consensus and that some endpoints might want to send ACKs on the path they received data, it would make sense to allow sending ACK_MP frames on an unverified path even though sending an ordinary ACK is prohibited due to it being a non-probing packet (though as stated in #50, I do not know if there is a reason to forbid use of most (read "non-probing") packets on an unvalidated path when we have per-path loss recovery and CC).