Virtual connection IDs in multi-hop settings

[kelmenhorst]

From my understanding, there is additional overhead at connection setup when using QUIC-aware in a multi-hop setting.
Let's assume a simple multi-hop proxy setup with P1 and P2 where both proxies should do QUIC-forward:
Client -- P1 -- P2 -- Target.

Due to the proxy choosing the virtual target CID, the client needs to

• setup a MASQUE connection to reach the target and learn its chosen CID,
• tell P2 about the target's CID via REGISTER_TARGET_CID,
• learn P2's virtual target CID from ACK_TARGET_CID,
• tell P1 about P2's virtual target CID via REGISTER_TARGET_CID (so that: virtual target CID of P2 == real target CID of P1) ,
• learn P1's virtual target CID from ACK_TARGET_CID,

in order to finally start forward mode on the uplink. Crucially, the above steps have to be done sequentially.
You can see that this overhead increases with each added proxy.

In the target to client direction, the problem does not exist because the client chooses the virtual client CID. The client still needs to make sure that for each set of adjacent proxies P(n) and P(n+1), where P(n+1) is closer to the target, it must hold that the virtual client CID of P(n+1) is equal to the real client CID of P(n).

I made a sketch about what I think the setup of virtual CIDs looks like: cids-multi-hop.pdf.

I don't have a solution for this and I don't know if one is needed but I think it should probably at least be mentioned in the draft if the mechanism to select/communicate virtual CIDs stays as it is now.

[DavidSchinazi]

Is your concern performance? At the start of the connection, tunneled mode can be used while this setup is happening, so it shouldn't introduce any delay. That said, you're right that we should mention this in the draft and mention that using tunneled can help avoid delays.

[mirjak]

I'm working with @kelmenhorst on this. We were also thinking if there is an easy way to improve this, e.g. by having the client pick both sides of the virtual CIDs. However, that would be problematic for load-balancing. Still, in any case, as you say @DavidSchinazi, it would probably helpful to discuss this in the draft as it needs to be considered during implementation and it wasn't obvious when we started.

[DavidSchinazi]

Letting the client pick both is tricky because it violates the general QUIC mindset of having the receiver pick its own CIDs. See the related discussion in #104.