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

[Spencer Dawkins at IETF <[e-mail]>]

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.html (extracted,
please feel free to correct me if I'm misrepresenting anyone):

*[23:48:45]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:48:45.357561>
<[e-mail]
<[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]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:48:46.658966>
<sftcd> could be, fine question though
[23:48:47]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:48:47.474340>
<hta> jonathan: I don't regard drop-from-queue as congestion control.
[23:48:55]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:48:55.904420>
<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]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:49:00.650063>
<[e-mail]
<[e-mail]>> carrick: you can have quic over quic. It's just not
specified yet*

*[23:49:02]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:49:02.352887>
<achernya> There's
no specification for anything-over-QUIC over than h3[23:49:10]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:49:10.785012>
<achernya> *other
than, rather*
[23:49:15]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:49:15.956316>
<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]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:49:18.593009> <
[e-mail]> I see, thanks
[23:49:25]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:49:25.634095>
<Martin
Thomson> Ted.h: appreciate it, thanks
*[23:49:30]
<https://www.ietf.org/jabber/logs/masque/2020-03-24.html#23:49:30.856183>
<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]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:35:32.68890>
<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]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:35:45.447758>
<[e-mail]> I also support adoption of this draft.
[22:36:38]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:36:38.771346>
<[e-mail]/barnowl> schmansport sessions?

*[22:36:40]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:36:40.118114>
<hta> Session
transport![22:36:41]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:36:41.310567>
<spencerdawkins> Is
there an agreed upper interface for QUIC that is not HTTP/3?*
[22:36:48]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:36:48.169519>
<[e-mail]> +1 on what Mark said
[22:36:49]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:36:49.696124>
<[e-mail]> WebSockets/2
[22:36:49]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:36:49.855420>
<brong> SPLITTERS
[22:36:54]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:36:54.772286>
<[e-mail]> about "transport"
*[22:37:07]
<https://www.ietf.org/jabber/logs/webtrans/2020-03-27.html#22:37:07.443469>
<[e-mail]
<[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]
> ----------------------------------------------------------------------
>
>
>