Hi Yanmei, thanks for explaining. Comments inline:
We have discussed about using different keys in different paths. This requires adding a key derivation procedure for each path, and also adding ways to identify the relevant key in the incoming packets, and we will have to modify the QUIC-v1 packet headers to support the feature. Why can’t you use the connection ID to find this information? It is needed to find the connection anyway, and you need it in the IV, so it should be trivial to store a local key ID along with CID lookup pointing to the connection, or am I missing something? It is true that you need a key derivation, but that machinery is already in place in QUIC-TLS, altough some details need to be added. As we have explained in the basic design principles of the proposal, we don’t want to modify the packet header format of QUIC-v1, to avoid the risk of packets being dropped by middleboxes (which may only support QUIC-v1). No, that would not be good. It also wouldn’t really be a QUIC-v1 extension. I’d like to express a little more, we have discussed a lot about this problem: As the management of paths is largely specific to application, Why we will need a frame that one endpoint use it to dictate the behaviour of the peer? 1. In uploading scenarios, as the sender side, client can decide the scheduler strategy itself, by providing APIs to let applications specify their path management preferences etc. 2. In downloading scenarios, as the receiver side, client need to express its preference of these paths. For example, client may need to tell server which path is preferred to use (maybe Wi-Fi path when there are both cellular and Wi-Fi environment). In the case client sends a management frame says "send on path #1 (the Wi-Fi path)", if server sends on path #2 (the cellular path), it will make users spend more traffic costs, and users will not be happy with that. Yes, that all makes sense. Without the management frame in the transport, we will not be able to explain that preference of paths. Servers will never know which path client is prefer to use. This is what I do not understand. Why do you need it in transport instead of the app level. Well, yes, as a general preference maybe it does make sense. But sense transport cannot distinguish between different kinds of payloads: different streams, different datagrams etc., all it can do is to apply this to all content. Furthermore, what if it is not upload or download, but something far more complex, like a game server that sends realtime location data on game objects and the game client sending player actions the other way, both at low latency. At the same time the game server sends new scene data in high bandwidth, high latency, in the background, and the client and server uploads voice chat with different priorities. Even if we forget about that complexity, what if both endpoints want to change priorities of the path because of different content. Who gets to decide? So I agree about the need to manage paths, but I think it needs to be at the application protocol level, just likely the now abandoned HTTP/3 prioritised streams were decided in the app protocol, not in the transport. So we start from simple and clear design of path states (0- Abandon 1- Standby 2- Available), and we added priority for scenarios like endpoints want to send 20% packets on one path / 80% packets on the other. Both client and server can send the PATH_STATUS frame. Yes, but I think this will lead to problems, even though I fully agree that paths needs to be managed somehow. If you compare to QUIC-v1, the transport spec does not say anything about how to schedule and prioritize streams even though it does suggest using pacing and does provide some guidance. This is not because scheduling is not important, because it is, but transport is not the right place to do it. Also here, you can imagine that it is the receiver, and not the sender, that should decide. Yet there is no priority frame in the transport spec. Thanks again for all the feedback! And thanks for the great work. I think it is important work.
