The definition of path

[nandsky]

As described in 1. Introduction

A path is determined by the 4-tuple of source and destination IP address as well as source and destination port. Therefore, there can be at most one active paths/connection ID per 4-tuple.

And @kazuho also discussed about this definition in https://github.com/quicwg/multipath/issues/233#issuecomment-1614032733

If I understand correctly, paths as defined by the multipath draft are identified by the 4-tuple. Each endpoints retain their mapping of DCIDs and paths. Loss recovery and congestion control are also handled by the 4-tuple.

My question is whether it is possible to define path only with destination IP and port?

1. multipath is a sender strategy to improve sending efficiency like congestion control. When I implement multipath, I just send the frame datas to different destination address (ip and port) and don't care about the source address.

2. In nginx implmentation, the object receving quic packets is called ngx_quic_socket_t which associated with the server cid, the object sending the message is called ngx_quic_path_t which is associated with the client cid. From a server perspective, a path object can be identified by the cid generated by the client, and the path object don't care about the source address.

[huitema]

Look at what happens when a mobile devices establishes two paths to a server, one for Wi-Fi and one for Cellular. In both cases, the packets are sent to a single destination address, that of the server. But there are two paths. Devices solve that either by using several UDP sockets bound to different local addresses, or by setting the source address option in calls to sendmsg().

[yfmascgy]

As described in 1. Introduction

A path is determined by the 4-tuple of source and destination IP address as well as source and destination port. Therefore, there can be at most one active paths/connection ID per 4-tuple.

And @kazuho also discussed about this definition in #233 (comment)

If I understand correctly, paths as defined by the multipath draft are identified by the 4-tuple. Each endpoints retain their mapping of DCIDs and paths. Loss recovery and congestion control are also handled by the 4-tuple.

My question is whether it is possible to define path only with destination IP and port?

1. multipath is a sender strategy to improve sending efficiency like congestion control. When I implement multipath, I just send the frame datas to different destination address (ip and port) and don't care about the source address.
2. In nginx implmentation, the object receving quic packets is called ngx_quic_socket_t which associated with the server cid, the object sending the message is called ngx_quic_path_t which is associated with the client cid. From a server perspective, a path object can be identified by the cid generated by the client, and the path object don't care about the source address.

Your problem there was a confusion of path definition with path identification. For path definition, you need 4-tuple. Otherwise, there is going to be the ambiguity issue as Christian just mentioned. When you have path established, you can surely identify a path using cid, which is also specified in the draft.

[nandsky]

Look at what happens when a mobile devices establishes two paths to a server, one for Wi-Fi and one for Cellular. In both cases, the packets are sent to a single destination address, that of the server. But there are two paths. Devices solve that either by using several UDP sockets bound to different local addresses, or by setting the source address option in calls to sendmsg().

@huitema Thank you for reply, I should also think about this from the client(the path of initiator)'s perspective.

[nandsky]

@huitema @yfmascgy Actually I'm always confused about these descriptions of 4-tuple, connection id used by server but provide by client, or vice versa and the direction of path_abandon.

1. In contrast with client (path of initiator) needs bind to different source IP and port in UDP layer, server only needs destination IP and port, so if 4-tuple consists of client ip and port as well as server ip and port, it seems only client ip and port will be used in multipath?

2. As describe in 1. Introduction

   If the 4-tuple changes without the use of a new connection ID (e.g. due to a NAT rebinding), this is considered as a migration event.

In the NAT-rebinding scenario, only the source ip and port of client changed instead of 4-tuple in server perspective.

3. The direction of PATH_ABANDON Will sending PATH_ABANDON from server to client with cid provided by server triggers the path (4-tuple?) to close? If this action is proposed by multipath, it seems we need to keep the mapping relationship between cid provided by server and cid provide by client, but RFC9000 does not require this. I asked a similar question in #269 .

[nandsky]

I am trying to implement multipath based on NGINX QUIC, and the model is as follows:

annotations:

1. This model is based on NGINX QUIC implementation, with the following mapping relationship: a. QUIC SM: ngx_quic_connection_t b. socket: ngx_quic_socket_t c. path: ngx_quic_path_t d. send_ctx: ngx_quic_send_ctx_t e. recv_ctx: splits from ngx_quic_send_ctx
2. This model splits 4-tuple into serverCID-bound RX and clientCID-bound TX, which generally differ in number.

"A path is determined by the 4-tuple of source and destination IP address", this sentence implies that a path object needs to contain 4-tuple, but in fact, as shown in the above model, splitting the 4-tuple object into TX and RX is more flexible. So, can the draft weaken the relationship between path and 4-tuple?

[LPardue]

"A path is determined by the 4-tuple of source and destination IP address", this sentence implies that a path object needs to contain 4-tuple, but in fact, as shown in the above model, splitting the 4-tuple object into TX and RX is more flexible. So, can the draft weaken the relationship between path and 4-tuple?

From the protocol perspective the path has two ends and is bidirectional. From the server perspective, its an endpoint and can discard some of the dual endpoint considerations. It is natural for implementations to split Reception and Transmission, that's a common design pattern.

I don't see any issue with the current definition of path; implementations are free to model that how they see fit.

[mirjak]

Can we close this issue?

[LPardue]

I'm not seeing any action to take.

[nandsky]

Thanks to everyone for explaining this to me. yes, we can close this issue.