"SHOULD" use ACK_MP frames?

[kazuho]

At the moment, section 5.1 states:

As soon as the negotiation of multipath support is completed, endpoints SHOULD use ACK_MP frames instead of ACK frames to acknowledge application data packets, including 0-RTT packets, using the initial Connection ID with sequence number 0 after the handshake concluded.

As @qdeconinck states in #181 (comment), my understanding is that ACK frames are equivalent to ACK_MP frames carrying DCID value of zero. Omission of value zero saves one byte per ACK frame.

Is the optimization worth the cost of supporting such omission?

If we think it might be valuable, I think we'd better change the text to state as such rather than discouraging the use of ACK frames (by saying "SHOULD use ACK_MP").

If we agree that it is not valuable, I would propose to change the specification to state that only ACK_MP frames can be used in the application data space when use of the multipath extension is negotiated.

[marten-seemann]

I agree that saving one byte for the very first CID is not very valuable, and I agree that it would be a really nice property to only use ACK_MP frames for the application data space.

[mirjak]

The only "valuable" case I can see is that if you negotiate multipath support but then don't use any additional path, your behaviour would not need to different from single path QUIC. Not sure how valuable that is. Therefore I think we want to encourage use of the ACK_MP.

However, I also don't really see the value of enforcing the use of ACK_MP...? You have to handle normal ACK frames anyway in the handshake. Why would a MUST make any real difference here?

[kazuho]

I think there are two reasons to forbid ACK being used in the application packet number space.

The first reason is that having less variation is better. In my view, having less variation on wire reduces the amount of tests that we have to write, helps us improve software quality. In QUIC v1, I recall we tried to tighten what can be sent on the wire, calling out numerous unnecessary cases as protocol violation.

The second reason is that we might want to change how acks behave (e.g., if ack is a probing frame; see #226). We can define the properties of ACK_MP, but there would be a lot more friction to change that of ACKs. So the trade off here is if we want to have two types of ACKs that behave differently, or just one.

[mirjak]

I'm not convinced. I'm not sure we have a good solution for #226 yet and I think we should minimise the difference to ACK as much as we can. I guess we need more input from the working group!

[yfmascgy]

The original intention was that in case when multipath was negotiated but only one path was employed, the multipath could smoothly fall back to single path and behave just like the single path QUIC. This is designed for situations like when your client's SDK and server support multipath quic but your cellphone only has one interface to use (Wifi is not connected or cellular data is turned off). If we force the use of ACK_MP, then the their behaviors diverge before a second path is added.

Regarding the issue #226 , I think maybe we still want to keep ACK_MP as non probing, and try to ack the probing frame from a path that has already been validated.

[huitema]

In your idea, @yfmascgy, how does this client react after rotating the CID, or after the peer rotates a CID, or after a NAT rebinding is detected? Do they still go on using ACK?

[mirjak]

Did we reach any agreement here? Can we close this issue without action?

[mirjak]

I believe the discussion is basically about changing the SHOULD to a MUST or a MAY. If we say MUST, we can't really enforce it because the normal ACK frame is still used during the handshake and there is no clear moment when it has to change. We could say MAY to encourage it more to actually use the normal ACK frame for path 0 packets. The use case for this is when multipath is negotiated but you are only using one path (with path ID 0). However, a SHOULD covers this use case as well and it sounds like people do actually prefer if later during the connection only one kind of ACK is used.

So in conclusion it sounds like the SHOULD is still fine. We could add one more sentence as say that the only case where not using MP_ACK makes sense is when only path 0 is used. Do we want to do that?

Otherwise I propose we confirm this conclusion during the IETF-120 meeting and close this issue!

[mirjak]

the not very conclusive decision at IETF-120 to keep the SHOULD. So we could close this issue without further action. However, we may want write some more guidance on why/when the SHOULD is useful.