Proposal: Explicit path identification

[qdeconinck]

I think given the dynamic nature of the CID usage on paths that leads to some existing design issues(see #137, #158), it is worth having some stable path identification (to address, e.g., #169).

What does not change

I think we now agree that a Multipath QUIC connection uses different Connection IDs on different paths, and each Connection ID has its own packet number space. Such a design enables end-hosts to easily receive packets and decrypt them without assuming anything about the network path (relying directly on the perceived 4-tuple makes the approach fragile). Note that we keep the ACK_MP as it (i.e., we acknowledge packet numbers that used a specific DCID).

Identifying network paths (until now)

So far, end hosts directly maps the (Destination) Connection ID sequence number as the path identifier of the network path. This path identifier is then used in the path-specific frames (PATH_ABANDON, PATH_STATUS,…). Such an approach has the advantage that we do not have to define additional signalling to identify a network path, and it is relatively easy to track that. However, this means that if one endhost changes the DCID it uses over a given path, this means its identifier changes. Having such dynamic changing identifiers for a stable path causes design issues when using an identifier no more valid in the path-specific frames.

Proposal: explicit path identification advertisement during path validation

The path validation process establish the identification of a path through the advertisement of the “Entry Point ID” (EPID) used by the packet sender. Each path is identified by a tuple (local EPID, peer EPID). This identification is then used in the path-specific frames to identify the concerned path. Note that each endhost uses EPID 0 on the initial path.

This implies that we need an augmented version of the PATH_CHALLENGE/PATH_RESPONSE frames (let’s say PATH_CHALLENGE_MP/PATH_REPSONSE_MP) that include the EPID that the sender used to send the frame.

Example

Let’s consider this initial situation.

  DCID 0 EPID 0                   DCID 0 EPID 0
   +------------------------------------+
   |                                    |
Client                               Server

In this initial state, each endhost has one path:

Client

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0

From the server perspective, we have

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0

Now the client wants to create a new path on a new local address, but still on the same server address (same IP and port at server side). When the server just processed the PATH_CHALLENGE_MP(data, EPID=1) sent by the client with DCID seq 1, we have this state:

Client

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 1, ???) using DCID seq 1

Server

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 0, EPID 1) using SCID seq 1

Note that the server can figure out at packet reception on which local address it saw, and thus map the corresponding local EPID to the new seen path. The server can then replies with a PATH_RESPONSE_MP(data, EPID=0) (and also initiates a PATH_CHALLENGE_MP as well). Assume here it uses the DCID with seq 2. Once the PATH_RESPONSE_MP is received by the client, we have this state.

Client

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 1, EPID 0) using DCID seq 1 and SCID seq 2

Server

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 0, EPID 1) using SCID seq 1 and DCID seq 2

Now the client can refer to the lower path in PATH_STATUS/PATH_ABANDON frame using (1, 0), and the server could use (1, 0). Note that it makes also possible to extend these frames to the set of paths sharing a given EPID. This tuple is stable as long as end hosts do not change the EPID they use when performing further path validations.

  DCID 0 EPID 0                   DCID 0 EPID 0
   +------------------------------------+
   |                                    |
Client                               Server
   |                                    |
   +------------------------------------+
  DCID 1 EPID 1                   DCID 2 EPID 0

Consider now a specific edge case, that is also hard to handle with the current (CID identification) design: the client decides to change the DCID it uses (now seq 2) on its path (EPID 1, EPID 0), but the very first packet sent experiences a NAT rebinding, making the server see a new 4-tuple. The end hosts’ states just after the server received that packet is

Client:

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 1, EPID 0) using SCID seq 2 and DCID seq 2

Server:

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 0, EPID 1) using SCID seq 1 and DCID seq 2
• (EPID 0, EPID ???) using SCID seq 2

To address this new unknown path, the server will initiate path validation over that new path using a new DCID (let’s say with seq 3), so it sends a MP_PATH_CHALLENGE(EPID=0) on the lower path. Once the packet reaches and after its processing, we have

Client:

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 1, EPID 0) using SCID seq 3 and DCID seq 2

Server:

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 0, EPID 1) using SCID seq 1 and DCID seq 2
• (EPID 0, EPID ???) using SCID seq 2 and DCID seq 3

Finally, the client replies with a MP_PATH_RESPONSE on its perceived EPID (hence EPID 1) and the response can reach the server, which can then figure out that the path is actually the same as the previous one (it experienced involuntary 4-tuple change, this is not a new path). The final state is hence

Client:

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 1, EPID 0) using SCID seq 3 and DCID seq 2

Server:

• (EPID 0, EPID 0) using SCID seq 0 and DCID seq 0
• (EPID 0, EPID 1) using SCID seq 2 and DCID seq 3

Additional remarks

Introducing such additional identifiers may require additional care to cope with EPID that change over a same address or to avoid a same EPID over multiple 4-tuples. I think we can require that new EPID values cannot decrease (monotonically increasing) and observing a same EPID coming from different addresses probably indicates that something is wrong there.

We can also extend the required state of a path to be "Active", i.e., we need to have both local and peer EPID of a path before considering it as active.

Having two endpoint-specific values instead of a single shared one (as suggested by #170) may be desirable to support the edge case mentioned above.

[yfmascgy]

Thanks for this intriguing proposal. But there will be a new issue if I understand correctly, and please correct me if I am wrong.

For example, what if a path has actually migrated because of changes in the underlying hops while the client and server's entry points (interfaces) remain the same. Then after exchanging the EPID information, the client and server will draw the conclusion that the path is not changed, which is not true.

[huitema]

I think this would be a big change from the existing draft and the existing consensus, which very explicitly says that we are using the path mechanisms of RFC 9000.

The number space is tied to the CID, because of encryption. That does mean that when we are sending ACKs, the "path ID" in the ACK is the ID used when the packets were sent.

[LPardue]

This sounds like a design change proposal, so I suggest also creating thread on the WG list to increase visibiltiy

[mirjak]

Let's continue discuss in issue #169.

[qdeconinck]

Given the changes it would involve (and the relatively low gain of the result), I think sticking to the DCID sequence number to identify paths is fine. I can keep this issue open for reference purpose.

[Yanmei-Liu]

I think PR #292 could also solve this issue : )

[Yanmei-Liu]

Closed as PR #292 has been merged.