As I’ve considered multipath more and more, I am more convinced that it should be solved between the application and the connection, not between the connection and the transport. For instance, an HTTP session should be able to use multiple connections (we already have that, kinda, but only for non-overlapping ranges/requests), and so long as we can define and/or discover the relationships between the connections (e.g. when the endpoint is the same but the connections are different), we have solved much of the problem-space.
In other words (and I hope my expression of this is redundant), multi-path really is about defining and mapping the session onto the lower level things. -=R From: QUIC <[email protected]> on behalf of Lucas Pardue <[email protected]> Date: Friday, October 16, 2020 at 4:25 AM To: Mirja Kuehlewind <[email protected]> Cc: David Schinazi <[email protected]>, QUIC WG <[email protected]>, Mike Bishop <[email protected]>, MASQUE <[email protected]> Subject: Re: [Masque] HTTP DATA frames for HTTP CONNECT? On Fri, 16 Oct 2020, 09:45 Mirja Kuehlewind, <[email protected]<mailto:[email protected]>> wrote: Hi David, I was sending this request to exactly understand if or what the issues are/could be in not having the DATA frame. Can you maybe further explain which issue you see? I can't speak for David but the issues I forsee come from additional code paths needed to support the feature. The frame parsing code needs to become HTTP method-aware, which is not the case in the implementation I own. With QUIC chair hat on: this is very late to be proposing design changes. It might even be too late. I'm setting a high bar here for compelling evidence or support that something needs to be changed. Cheers Lucas masque<https://www.ietf.org/mailman/listinfo/masque>
