Clarify support of migration

[mirjak]

RFC9000 allows endpoints to change the CID any time on a path. So it's not automatically a new path if a new CID is seen. This should be noted explicitly in the draft.

Further, also migration can happened without endpoint control (NAT rebinding). In this case the server will see a new 4-tuple but no CID change. In line with RFC9000 the server should start path validation and then the client should use a new CID. In case of multipath support we need to clarify if and when this is treated as a new path. If seen as a new path, we would probably need to close the old one (which however is not functional anymore). However, if e.g. only the port number changes, RFC9000 also would also to not reset the congestion control. In this case it would make sense to not treat it as a new path.

[yfmascgy]

I agree. I think we might add sth like:

   New CID ---yes---> new 4-tuple ---yes---> new path
       |                  |
       |                  No
       No                 |
       |                  ---> use new CID on same path
       |
       ----->4-tuple change----yes----> only port number change ----yes----> NAT rebinding ( do not rest CC)
                 |                                 |
                 |                                 No
                 No                                |
                 |                                 -----> connection migration & reset CC
                 |
                  -------> no change

[michael-eriksson]

@yfmascgy, I think your decision tree above is too brittle. In particular, if an implementation has a time-based CID change policy, it's very easy that both the CID and the NAT binding change at the same time after an idle period.

As I have indicated elsewhere, I think that there should be a PATH_SETUP (or maybe PATH_MANAGEMENT) frame, where path setup, CID change etc can be explicitly signaled. Implicit path setups and CID changes are just too vague and error prone...

[mirjak]

I created PR #172 that states that any path validation creates a new path (even if only the port changes). I believe this is more clear and avoids inconsistencies on both sides. However, we might discuss this case a bit more.

[yfmascgy]

@yfmascgy, I think your decision tree above is too brittle. In particular, if an implementation has a time-based CID change policy, it's very easy that both the CID and the NAT binding change at the same time after an idle period.

The current draft manages the path idle issues with "Sending periodic PING frames also helps prevent middlebox timeout." Sending periodic PINGs to keep a path alive should greatly reduce the chance of such a NAT rebinding. So I am wondering is it a corner case? and is it worth adding new frames to address it?