Lucas,
There are currently three MPQUIC based proposals which are in discussion with different variations in regard to what is transported and how it is transported. This is why I’m not commiting to clearly indicating one mode of transport or another. >From my side we are happy in advancing the work in draft-piraux-quic-tunnel and use it as base of our solution. -Florin *From:* Lucas Pardue [mailto:[email protected]] *Sent:* Monday, October 19, 2020 5:51 PM *To:* Florin Baboescu <[email protected]> *Cc:* Spencer Dawkins at IETF <[email protected]>; WG Chairs < [email protected]>; IETF QUIC WG <[email protected]>; Flinck, Hannu (Nokia - FI/Espoo) <[email protected]> *Subject:* Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim Hi, On Tue, 20 Oct 2020, 01:41 Florin Baboescu, <[email protected]> wrote: Hi Lucas, When you say “Is it the intention to map QoS flows to QUIC streams?” In short I can say yes. If it is available. I consider though this to be an orthogonal discussion to the multipath one and I believe it to be dependent onto the current progress with the QUIC tunneling draft. It can't be orthogonal. We need to understand what your requirements of the QUIC transport are. QUIC presently defines two methods to carry data in a connection streams and datagrams. How those map to multipath for your needs is the question here. There are many QUIC tunneling drafts. Can you be more specific? Cheers Lucas
smime.p7s
Description: S/MIME Cryptographic Signature
