Hi Olivier, all, > 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.
The main difference is that the ATSSS proxy will be ** explicitly signalled ** to the UE while the presence of any other on-path proxy is ** transparent ** to the UE. The explicit mode in the ATSSS allows an UE to probe the path, react to path failures, decide to bypass the proxy, etc. Cheers, Med > -----Message d'origine----- > De : QUIC [mailto:[email protected]] De la part de Olivier > Bonaventure > Envoyé : lundi 26 octobre 2020 09:38 > À : David Schinazi <[email protected]>; Florin Baboescu > <[email protected]> > Cc : QUIC <[email protected]> > Objet : Re: More context on ATSSS use case > > 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 } -------/ > > > 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. > > > 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
