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

[Yanmei Liu <[e-mail]>]

Hi Mikkel,

First of all, thanks a lot for reading the draft carefully and giving feedback about it.
My reply is behind the quote: 

> Some more comments on the proposed MP design
>
> On protocol violations:
>
> quote:
> “If an endpoint receives MP frames from packets of other encryption
> levels, it MAY return MP_PROTOCOL_VIOLATION as a connection error and
> close the connection."
> 
> I think it is important to use strict MUST on easily detectable protocol violations to ensure interop and security.

It’s a good advice and we will using MUST here in the next version.

> Also, to my previous point on path sequence numbers as IV source:
> What is the motivation for using the same key on all paths? Is it considered a resource constraint to have more keys? Considering a server might have 10K+ connections, and perhaps 1.3 paths per connections (wild guess), it doesn’t seem to much of an overhead.
> In addition, having separate keys avoids the sync issues mentioned in the document. As it stands, failure on one active path can block key update. This sounds like an accidental or intentional attack vector, although I’m not sure that it is.
> 

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. 
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).

> On the document format:
> 
> I think the discussion on application influence is good, but maybe isolate that discussion a bit. It seems that stream priorities are part of the MP design, which isn’t really the case, even if it is relevant to MP applications.
> 

We do encounter scenarios where stream priority needs to be supported in multi-path in reality, and we will discuss this carefully.

> On QoE:
> Maybe it is good to leave the interpretation open to applications, but it makes it more difficult to design a protocol layer on top. Is it the intention that, for example, a QUIC-> MP video protocol is designed which then documents how to interpret QoE? If so, does this need to be in the MP protocol, or could it be in a control stream created by the app level protocol? In other words, I’m not sure wha the value is at the transport level if it doesn’t > affect the transport layer directly (unless of course I am missing something).
> The QOE_CONTROL_SIGNAL frame will definately affect the packet scheduler, as mentioned in the proposal. 
> And we didn’t restrict the inner value format, it’s open for implementors and researchers to play with it, and try their own scheduler algorithms with it. 
> We thought it would be convenient to play with an existing frame than adding a new frame. 
> ACK_MP frame:
> If this is an extension to QUICv1 it makes sense (and this seems to be the case). If it is intended as a new protocol version, maybe replace the regular ACK frame to avoid protocol bloat? I can see the counter argument that a new frame ID makes it easier to reuse v1 im> plementations, but protocol bloat is a concern as well.

I think that it’s important to keep compatible with QUIC-v1. If implementations send ACK frame in multiple paths, it still need to be processed without errors.

> The scheduling section has an example mentioning one of the two paths. I’m sure this a left-over since there could be more than two active paths as I understand.

We will add more examples about scenarios with more than two active paths.

> Path state:
> I do not understand this well enough, but I’m a bit concerned about one endpoint dictating the behaviour of the other regarding priorities etc. It seems like this could easily be abused, and perhaps this is also better done in an application level protocol?
> The text is not very clear about the client and the servers role in path negotiation. It seems that that it follows he QUIC-v1 async design due to relying on the v1 PATH packets. So presumably this also places constraints on who can send path state updates.
> If MP was to become more symmetric, I wonder if there is a natural evolution from here, or the proposed design is just digging the async design hole deeper, so to speak. Note that async MP is useful in its own right.

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. 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.
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. 

Thanks again for all the feedback!

Thanks,Yanmei