Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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.