Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]

[Martin Thomson <[e-mail]>]

If I read this liaison correctly, this is effectively a request to keep 3GPP in the loop.  The request to do multipath is more implied than anything else.  I think that the explicit request is fine.  The implicit one maybe less so.

I suspect that work here would go faster if we had more input on the hard multipath problems.  That's not the spelling of the protocol (that's almost trivial, as demonstrated in proposals), but the assignment of different information elements paths that might have different characteristics.  What I heard in Zürich was that this was less of an engineering problem than a research one.

I'd be interested in having active engagement from people who have use cases. Specifically, I would seek to learn whether this is truly a research question or whether there are simplifying assumptions that might make the problem tractable for some use cases.

The more I think on this subject, the more that I think it was a mistake to charter to do multipath.  I don't believe that we properly answered the standard BoF questions with respect to this topic.

On Thu, Apr 2, 2020, at 01:15, Magnus Westerlund wrote:
> QUIC WG,
> 
> The IETF has received the attached Liasion statement (
> https://datatracker.ietf.org/liaison/1678/) that is intended for the QUIC WG.
> Please review it and the WG should considerd sending information to 3GPP as
> requested at key points in the process of the multi-path extension/version of
> QUIC. 
>  
> Cheers
> 
> Magnus Westerlund 
> TSV AD
> 
> 
> Attachments:
> * Email.eml
> * smime.p7s