Re: Use of multiple paths [was: Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]]

[Magnus Westerlund <[e-mail]>]

Thanks,

So I was groping after something more complex. So basically the definition of
reliable multi-stream usage of QUIC that has an ALPN to identify that there it
is up to the application to interpret how the streams are used. A sort of "TCP
socket" for QUIC? Which might also imply some basic constraints on the API
between the application and the QUIC stack? 

Magnus

On Mon, 2020-04-06 at 17:20 -0500, Spencer Dawkins at IETF wrote:
> For what it's worth, 
> 
> On Mon, Apr 6, 2020 at 7:44 AM Magnus Westerlund <
> [e-mail]> wrote:
> > Hi Roberto,
> > 
> > Do you have a reference or can you expand on what functionalities you
> > actually
> > expect from a session layer? 
> 
> From https://www.ietf.org/jabber/logs/masque/2020-03-24.htmll (extracted,
> please feel free to correct me if I'm misrepresenting anyone):
> 
> [23:48:45] <[e-mail]> Can someone explain why you
> couldn't you have QUIC over QUIC? The payload would be the packet the proxy
> forwards.
> [23:48:46] <sftcd> could be, fine question though
> [23:48:47] <hta> jonathan: I don't regard drop-from-queue as congestion
> control.
> [23:48:55] <keithmoore> Magnus: but I also think that we're inevitably going
> to have something like this, whether we want it or not, including the
> potential for each app to negotiate its own relationship with an external
> proxy.   so we might as well try to understand the hazards.
> [23:49:00] <[e-mail]> carrick: you can have quic over quic. It's just
> not specified yet
> [23:49:02] <achernya> There's no specification for anything-over-QUIC over
> than h3
> [23:49:10] <achernya> *other than, rather
> [23:49:15] <Ted.h> @Martin I dropped Matt a note to ask for a citation; will
> forward to you if he has one that can be referenced.
> [23:49:18] <[e-mail]> I see, thanks
> [23:49:25] <Martin Thomson> Ted.h: appreciate it, thanks
> [23:49:30] <spencerdawkins> That's the problem - there's not a generalized
> upper interface for QUIC.  
> 
>  and, in https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html 
> (extracted, and please feel free to correct me ...
> 
> [22:35:32] <Martin Thomson> I also support adoption.  The requirements parts
> are mostly solid.  I have concerns about the composition of transports in the
> overview piece.
> [22:35:45] <[e-mail]> I also support adoption of this draft.
> [22:36:38] <[e-mail]/barnowl> schmansport sessions?
> [22:36:40] <hta> Session transport!
> [22:36:41] <spencerdawkins> Is there an agreed upper interface for QUIC that
> is not HTTP/3?
> [22:36:48] <[e-mail]> +1 on what Mark said
> [22:36:49] <[e-mail]> WebSockets/2
> [22:36:49] <brong> SPLITTERS
> [22:36:54] <[e-mail]> about "transport"
> [22:37:07] <[e-mail]> Spencer: draft-ietf-quic-transport ?  
> 
> So, ISTM that this question is banging around from venue to venue. Some people
> are assuming draft-ietf-quic-transport will work well enough for protocols
> that aren't HTTP/3, and others are not so sure. 
> 
> Definitely worth talking about, in what I hope is the near future ...
> 
> (It's also worth mentioning that 
> https://tools.ietf.org/html/draft-pardue-quic-siduck-00 appears in at least
> one of those jabber logs)
> 
> Best,
> 
> Spencer
> 
> > Cheers
> > 
> > Magnus
> > 
> > On Fri, 2020-04-03 at 19:15 +0000, Roberto Peon wrote:
> > > QUIC is currently missing a session layer other than H3.
> > > 
> > > I'm pretty unhappy about the idea of other protocols right now, since I
> > > believe moving forward without a generic session layer is a mistake we'll
> > all
> > > pay for in the future ( again).
> > > 
> > > -=R
> > > 
> > > On 4/3/20, 10:01 AM, "QUIC on behalf of Olivier Bonaventure" <
> > > [e-mail] on behalf of [e-mail]>
> > wrote:
> > > 
> > >     Hello Lucas,
> > >     
> > >     > I'll acknowledge that HTTP/3 isn't the only use of QUIC, but it is
> > a 
> > >     > comprehensive use of the transport features that has deployment 
> > >     > experience. 
> > >     
> > >     I agree that HTTP/3 has been the main use case for QUIC and that it
> > has 
> > >     influenced some parts of its design. However, I personally consider
> > QUIC 
> > >     as the generic transport protocol that will support a broad set of 
> > >     applications that will probably have different requirements than
> > HTTP/3.
> > >     
> > >     QUIC has a very clean and extensible design and architecture. It
> > opens 
> > >     new ways to think about the transport layer without all the problems 
> > >     that TCP has faced since roughly the last two decades.
> > >     
> > >     > So looking at MPQUIC thorough the lens of HTTP/3, streams 
> > >     > may not be truly independent because of their reliance on other
> > streams 
> > >     > such control or QPACK. 
> > >     
> > >     Agreed, but there are applications that will use independant streams.
> > A 
> > >     simple example is a standard file transfert and many existing 
> > >     applications that rely on a single bytestream. A TLS VPN that uses
> > QUIC 
> > >     instead of TLS/TCP could map each transported TCP connection over a 
> > >     different QUIC stream.
> > >     
> > >     > Furthermore, even if we model the streams as 
> > >     > independent HTTP requests, the reality is that there is often a
> > higher 
> > >     > layer that wants to put them back together and there the ordering
> > can 
> > >     > matter. These are elements of the puzzle for prioritizing
> > multiplexing 
> > >     > of streams.
> > >     > 
> > >     > Getting scheduling of HTTP streams right is really hard. With HTTP/2
> > > and 
> > >     > TCP today we see several server implementations that just don't do
> > it 
> > >     > very well and may never get around to fixing it. We've also seen
> > issues 
> > >     > in how servers adapt their scheduling to client reprioritization 
> > >     > signals. That seems quite relevant to this use case which requires
> > a 
> > >     > server to select an appropriate path based on client conditions.
> > >     > 
> > >     > The experience, to me, is a sign that people would struggle to build
> > an 
> > >     > HTTP/3 implementation (particularly server-side response
> > scheduling) 
> > >     > that achieves the theoretical goals of MPQUIC. Is it something that
> > can 
> > >     > be tested and shown to demonstrably outperform HTTP/3 plus
> > connection 
> > >     > migration in a statistically significant fashion? Maybe there are
> > case 
> > >     > studies of  HTTP/2 implementations that have tried adapting to
> > MPTCP, 
> > >     > which could inform an analysis for HTTP/3?
> > >     
> > >     In MPTCP, we were less ambitious than in HTTP/2 or HTTP/3 concerning
> > the 
> > >     packet schedulers. We considered that each host is independant and
> > that 
> > >     it uses its own packet scheduler. In contrast with HTTP/2, we did not 
> > >     define ways to prioritise one path over the other by exchanging 
> > >     information in the protocol (except the backup bit, but this disables
> > a 
> > >     path). In practice, what we observe is that the application selects
> > the 
> > >     packet scheduler that it needs locally. On Apple smartphones, this is 
> > >     the choice between the Handover and the Interactive modes for
> > example. 
> > >     This is not as powerful as negotiating packet schedulers over the
> > MPTCP 
> > >     connection, but seems a reasonable tradeoff from an engineering 
> > >     viewpoint based on deployment experience.
> > >     
> > >     
> > >     Olivier
> > >     
> > >     
> > > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------