Use of client/server

[mirjak]

Due to the copying&pasting from different documents, we use sometimes client/server and sometimes endpoint/peer in the draft. If I understand everything correctly, both endpoint can open (start validation) and close paths, correct?

There I would propose to remove all instances of client/server from the draft (expect for the handshake negotiation part). I can do that but wanted to check first if that's the correct thing to do

[huitema]

No, that is not correct. Only the client can open new paths, per section 9 of RFC 9000:

   This document limits migration of connections to new client
   addresses, except as described in Section 9.6.  Clients are
   responsible for initiating all migrations.  Servers do not send non-
   probing packets (see Section 9.1) toward a client address until they
   see a non-probing packet from that address.  If a client receives
   packets from an unknown server address, the client MUST discard these
   packets.

[mirjak]

Yes, I know this text in RFC9000. I was wondering if we can release this restriction?

For migration all use cases assumped that the client would move (or be NATed). However for multiipath I think there are also use cases where the server side might have multiple paths (e.g. in the proxy case).

So could we remove this restriction just, or are there problem with that?

[huitema]

The restriction is due to general considerations about NAT traversal, server farms, etc. I think we agreed already that this kind of deviation from RFC 9000 belongs in a separate extension, much like unidirectional paths or discovery of alternate server addresses. It should not be negotiated as part of the "multipath core". I would rather see that as part of peer-to-peer extensions.

[mirjak]

This restrictions makes sense for migration because you avoid the synchronisation problem what happen if both end try to migrate at the same time. However, this problem doesn't exist for multipath because if both end try to open a new path at the same time, you just open two paths. If there is no technical reason to keep this restriction, I don't still we should keep it artificially.

[huitema]

That's not the only problem. Most clients are behind some kind of NAT or stateful firewall, which will only let a packet in if it saw a packet out from the same 5 tuple. In such scenarios, migration originating from the server will just fail. If you want to make them work, you have to get a cooperation between client and server. In the case of big cloud servers, the solution is something like the preferred address extension: the server tells the client that it can also be joined at an alternate address, and the client opens a path to that. In the case of peer to peer servers, the solution requires something like ICE. These are valuable things to do, but they should be described in an extension, not in the core document.

[mirjak]

This is a problem for migration but if the server tries to open a path and it fails that just fine and not a problem. Signaling of alternative address to the client we already decided to leave to an extension. However, that still doesn't mean for me that we need to restrict the opening of new path to client.

[mirjak]

To address this point before the submission deadline, I think we should add something to the intro to clarify that new paths can only be opened by the client and maybe also say that this issue needs further discussion?

I will anyway make a pass and check all use of the terms client/server but keep it where appropriate.

Regarding path_abandon it seems okay to me that both ends can send it because it really just an indication that a certain path should not used anymore. I guess usually the client will send this, e g. due to a mobility event, but I don't see a reason to restrict this to the client only. I will propose some text to address issue #32

[mirjak]

In #32 I also changed one occasion of client/server. I think the other ones are fine (given the current restriction that paths can only be opened by the client). I will open a separate issue for this question but with the intention to solve it after submission of -00