Hi Mikkel, Thanks a lot for the feedback.
> I think this sounds like a good approach. It takes all the work an application would otherwise have to do and hides the complexity, without completely introducing a lot of new protocol complexity. This allows an application to open a stream and keep working on it regardless of which connections are currently alive. > I wonder if there are cases where this is a bit too heavy. For example handshakes could perhaps be simpler on secondary connections. Yeah, we also find that the handshake for the secondary sub-connections is a little too heavy, so we are trying to simplify it. > Also I wonder about privacy. For example if it is easy to detect that to concurrent connections belong to the same endpoint, fingerprinting might be easier. I guess that would always be a problem for MP. > There are also subtleties such as idle-timeout. What if each connection has a different timeout, is it only the sub connection that dies, or the entire connection? There could even be a case where connections remain alive without any currently open sub-connection in order to deal with aggressive NAT gateways etc. We allow each sub-connection to have a different timeout, and when one of them dies, the entire connection remain alive until all the sub-connections die (in our implementation). but we will take the situation dealing with NAT gateways into consideration. > If secondary handshakes get simplified, I suspect it is more of an implementation whether to see it as sub-connections, or just protocol messages on different paths. And thank you again for all the advice :) Thanks, Yanmei
