Implementing multipath on QUIC-aware proxies

[yfmascgy]

It seems that there has been a lot of interests in implementing multi-path on QUIC-aware proxies and there are certain implications this brings to the multipath base protocol (also see discussions on #214), we can put our thoughts under this issue so it can be better tracked. @kazuho @tfpauly @huitema

[tfpauly]

I'm not convinced that quic-aware proxying necessarily needs any changes from the base multipath spec--I view the proxy as doing transformations that are transparent to the server. But happy to discuss!

[kazuho]

I could very well be wrong, but I think there are things to consider.

If I understand correctly, paths as defined by the multipath draft are identified by the 4-tuple. Each endpoints retain their mapping of DCIDs and paths. Loss recovery and congestion control are also handled by the 4-tuple.

That means that a QUIC-aware proxy cannot coalesce packets arriving on different paths to a single source port. But how is a QUIC-aware proxy expected to recognize the path being intended by the sender? Using Connection ID for recognizing the path might not be a good idea, because Connection IDs can change on the same path. If the QUIC-aware proxy considers all the changes to Connection ID as migrations (and assigns new local ports), that might have negative impact on throughput, as migration requires the peer to validate the path before sending packets.

[kazuho]

To follow up, at the moment my preference goes to stating something like below in the QUIC-aware proxying draft:

• When the proxy receives packet with a new 4-tuple, it SHOULD allocate a different local tuple than that have been previously used for the same connection, and use that local tuple for forwarding packets arriving with the same 4-tuple.

In other words, require QUIC-aware proxies to preserve the view of paths as identified by 4-tuple.

[mirjak]

Actually congestion control and loss recovery is per packet space which is identified by the CID. Thus if the CID changes you have to reset cc and recovery (therefore you should not do that unnecessarily often). I think this means you could use multiple CIDs on the same 4-tuple without any design changes, however, it is also true that this case was not considered by this extension as it states in the intro: A path is determined by the 4-tuple of source and destination IP address as well as source and destination port. Therefore, there can be at most one active paths/connection ID per 4-tuple

Also, the QUIc-aware proxy approach does use multiple CIDs on the same 4-tuple, however, these packets that are forwarded e2e without decapsulation actually don't have cc and recovery state in the proxy.

[tfpauly]

Yes, I do think that the proxy that is quic aware needs to make each MPQUIC path be a separate path as viewed by the server, but I don't think that requires any changes to the spec of MPQUIC.

[kazuho]

It's good to see emerging concensus (which is non-action-needed on the side of Multipath draft).

Kind of off-topic, but @mirjak

Actually congestion control and loss recovery is per packet space which is identified by the CID.

Is that so?

I have been under the impression that while loss recovery is indeed per-packet-number-space, RTT measurement and congestion control is per-4-tuple. That is the model that we have in RFC 9002, which states that loss detection is separate per packet number space, unlike RTT measurement and congestion control (section 6.3).

Is there an reason to change CC behavior?

[mirjak]

@kazuho you are right. I wasn't considering migration and therefore over-generalising. However, I guess RFC9000 doesn't explicitly prohibit you to have multiple CCs per path ;-)

[michael-eriksson]

Actually congestion control and loss recovery is per packet space which is identified by the CID.

Is that so?

I have been under the impression that while loss recovery is indeed per-packet-number-space, RTT measurement and congestion control is per-4-tuple. That is the model that we have in RFC 9002, which states that loss detection is separate per packet number space, unlike RTT measurement and congestion control (section 6.3).

Is there an reason to change CC behavior?

I think that there is a bit of confusion here... The packet number spaces that RFC 9002 talks about are the encryption number spaces: Initial, Handshake and Application data. Without multipath, packets from all these number spaces go over the same single path and thus need to have common CC. Multipath number spaces are only defined for Application data (aka 1-RTT) packets and are a different thing.

[kazuho]

@michael-eriksson In both QUIC v1 and Multipath, endpoints might be forced to change the CID of an existing path (without changing the path) though NEW_CONNECTION_ID.retire_prior_to.

When that happens, with Multipath the packet number space is changed as well.

My point has been that endpoints do not need to reset CC in such event and that RFC 9002 is already designed with having multiple packet number space on the same path.

[mirjak]

I think it is still true that there are not changes need to the design of the multipath extension. Now that we have explicit path ID even less so. Therefore I'm closing this issue now. Please reopen or open a new issue if you think more discussion is needed!