search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 17 forks source link

MAX_PATH, sender initiated streams, and CID allocation. #322

Closed huitema closed 2 months ago

huitema commented 3 months ago

We have a lingering issue of whether to support sender-initiated paths or not. We have dodged this issue so far, because clients will often be located behind NAT or firewalls, which would cause server packets to be dropped if they did not match a 4-tuple previously used by the client. In that case, the server would not directly try to open paths, but might instead suggest IP addresses and port numbers that the client could use in path openings. But there are scenarios in which the client is not behind a firewall, and in which sender initiated path could be a performance improvement.

In the "unique path ID" scenario, we risk a collision if the sender and the client try to initiate different paths at the same time. Suppose that the client has addresses C1 and C2, the server addresses S1 and S2. The client is not yet aware of S2, and the server is not yet aware of S1. Path 0 has been established with the tuple C1-S1. The peers have both provided CID for Path-ID=1. The collision happens if, at the same time, client and server try to open path 1 as follow:

What follows depends on transmission order and local decisions, but is essentially non-deterministic. We might get a new path 1 with tuples C2-S1, C1-S2, or maybe C2-S2 or C1-S1.

We have discussed ways to avoid that, by splitting the "path ID" space in two. When the the client starts a path, it should use a CID with an even sequence number path, and the server should pick an odd sequence number space. The example above would become:

This becomes deterministic, which we like, but it makes the management of path numbers more complex. If we follow the rules set for MAX_STREAMS, we would need the following behavior:

  1. MAX_PATHS=N should be interpreted differently whether N is even or odd.
  2. MAX_PATHS=2*N+1 indicates the largest "odd" path number than the sender supports.
  3. MAX_PATHS=2*N indicates the largest "odd" path number than the sender supports.
  4. The largest negotiated odd number is the lowest of the MAX_PATHS odd numbers send by client and server
  5. Ditto odd numbers.
  6. Both peers MAY provide CID for even and odd path numbers, within the limits of values allowed.
  7. A new path can only created if both peers have provided MP_NEW_CONNECTION_ID with that path value
  8. Clients can only initiate even numbered paths, servers can only initiate odd numbered paths.

We need to decide now whether we want to do that. A fall back position would be to state that "this version of multipath only support even numbered path ID, odd numbers will be used if and when we support server initiated path-ID."

mirjak commented 2 months ago

@huitema thanks for writing this down. Given we have issue #328 can we close this issue now and have the discussion there? Or is there anything else that is missing in #328 from this issue?

huitema commented 2 months ago

Let's continue this discussion in issue #328.