Re: More context on ATSSS use case

[David Schinazi <[e-mail]>]

Hi Olivier, responses inline.

On Mon, Oct 26, 2020 at 1:38 AM Olivier Bonaventure <
[e-mail]> wrote:

> David,
>
> >
> >
> > [DS] Let me clarify why ATSSS introduces a new point of failure. First
> > here's the common network topology today without ATSSS. In this example
> > the Client is a smartphone, and the user is browsing a website hosted by
> > WebServer.
> >
> > [Client] ----- { cellular } ------- [WebServer]
> >      \------------{ Wi-Fi   } ------------/
> >
> > The client has (at least) two IP addresses: IP_Client_cell and
> > IP_Client_WiFi.
> > The WebServer has IP_Server.
>
>
> My understanding of most of today's QUIC deployments is that the client
> is not connected to the webserver but to a CDN or edge node that serves
> as a proxy to the webserver.
>
> Thus the setup is
>
> [Client] ----- { cellular } ------- [Edge]   ---------[WebServer]
>        \------------{ Wi-Fi   } -------/
>

That's absolutely correct, but it's also orthogonal to this discussion. If
I'm
communicating with a WebServer, the fact that it's behind an L3 router
or an L4 load balancer or an L4 load balancer or edge is transparent.
Yes, all of those are point of failures, but that's orthogonal to whether or
not ATSSS introduces one more point of failure in addition to all existing
ones.

> Now let's assume the Client is happily browsing using QUICv1 over one
> > interface, if that network goes down, QUIC will automatically migrate to
> > the other network and the web browsing will not fail. The client can
> > send packets to IP_Server on any interface and as long as one interface
> > works they will reach the server.
> >
> > Now let's introduce ATSSS:
> >
> > [Client] ----- { cellular } ------- [ATSSS Proxy] -------- [WebServer]
> >      \------------{ Wi-Fi   } ------------/
> >
> > The ATSSS Proxy has IP_ATSSS.
> > The packets sent by the client are not sent to IP_Server here, they're
> > sent to IP_ATSSS.
> > If the ATSSS proxy becomes unreachable mid connection, the client's
> > connection will break - because it's sending to IP_ATSSS not IP_Server.
>
> The client will detect the failure of the ATSSS proxy and will then be
> able to switch to non-ATSSS to directly reach the webserver/edge node.
> Since the client uses the ATSSS for multiple applications, a failure of
> the ATSSS proxy will be quickly detected.
>

How can it do this without the end-to-end QUIC connection failing?
Are you saying that the Client will migrate its end-to-end QUIC connection
away from the virtual ATSSS interface and go straight over Wi-Fi?

> My point is that in this scenario ATSSS reduces reliability by adding a
> > point of failure.
>
> I don't see a difference between the failure of an Edge node and an
> ATSSS proxy. Both can be deployed with enough redundancy to limit the
> impact of failures. The only difference is that ATSSS nodes will
> probably be deployed by network operators while Edge nodes are deployed
> by CDN providers.
>
> Olivier
>