Hi Folks,
Thanks so much for today’s discussion and feedback. We really appreciate it. After reading the notes and the chat logs. I see there are few misunderstandings that we would like to clarify, hoping this could provide more useful information and be more thought provoking. (1) Concerns about privacy: As a cloud provider (AliCloud), we typically own our backbone networks (i.e., routers) and load balancers. Since one can view load balancers as a sort of routers, having WAN routers that are capable of parsing info in path’s CID should not introduce any additional concern (The load balancer needs to parse CID anyway). Of course, we need CID obfuscation (the same as the LB case) for packets that leave our network. (2) Is it hard to orchestrate?: No, on the contrary, it is quite easy to do so. It is about how to expose network TE capability to applications. We have experimented with this feature and our experience shows that it can be done with a very simple config. Our backbone network is formed by various tunnels via segment routing tunnels (SR-MPLS or SRv6) and you just need a mapping rule for an edge router to pull from a centralized SDN controller. After that, you update QUIC’s CID generation policy in user space and that is done. (3) Why not DSCP? It turns out that setting DSCP may not be as simple as it looks. First, setting DSCP could be destructive. Because you don’t know if the network other than your network will do anything “unexpected” regarding this DSCP value. Second, DSCP values can be easily filtered or modified. There are many other middleboxes in cloud infrastructure between the network and your real server (gateways, LBs, firewalls, layers of switches). Ensuring they all respect DSCP values is not easy. Moreover, in the uplink, mobile carrier and wifi APs could change your DSCP value. Third, as setting DSCP value can have unexpected effects, in a production environment, we avoid giving tenants the privilege to set DSCP. We typically let our network infrastructure set the DSCP value as needed, but it is then very hard to do different DSCP for each socket. (4) How can fine granularity within a connection help? There are many use cases. One example is to retransmit loss recovery packets on a faster path. If there are packet losses on the regular path, it could mean that the regular path is experiencing high queueing delay, then why not send a loss recovery packet on a fast track which has small queues along the way? (5) Will my application try to abuse the network to set all traffic to high priority? It is not in the application’s interests to do so because fast paths cost more and they will be charged more. It should only use a high priority path when necessary. Let the economy work. (6) Why not always deploy your servers at the edge? It is not always possible. Edge pops have limitations in the number of servers they can support. There are many factors (cooling, electricity, space). Moreover, cloud todays are mostly hosted in data centers. (7) Can this be done with multipath + PATH_STATUS? No, this is not enough, because you need your network to understand how to apply TE policies to set the sequence of hops in the first place. Otherwise, you may not have multiple paths to begin with. Cheers, Yunfei On Tue, Jul 25, 2023 at 2:48 PM Lubashev, Igor <ilubashe= [email protected]> wrote: > On July 25, 2023 5:28 PM Lucas Pardue <[email protected]> wrote: > > - On Tue, 25 Jul 2023, 14:15 Border, John, <[email protected]> > wrote: > > I guess I may have a different view of who an end user is. For example, I > see the people working in a bank as end users. But, I realize that this > has never been the general view. > > > - Workers in a bank are end users with specific needs, that of both > the individual and their employer. In designing their systems of access, an > employer might need certain forms of visibility but also certain kinds of > security assurance. The conflict arises where a stakeholder that is neither > the employee or employer might wish to create an architecture or deployment > that suits their own needs (such as revealing information that would > otherwise be private in order to achieve some goal) without accommodating > the end user needs. > > > > That’s right. Per RFC 8890, the philosophy is to identify all possible > users and focus on minimizing the harm to those who are worst off. If no > one is reasonably worse off, helping bank employees is a great goal. > Applications signaling information to the network are not a problem, as > long as the users are given a reasonable choice to signal or not to signal > without suffering severe consequences if they chose privacy. > > > > In a corporate environment, the bank owns endpoints (laptops, phones), so > those can run whatever software is required for the bank’s security and > compliance purposes. If those devices need to be interoperate only with > the corporate networks (instead of the Internet), this can be done outside > of QUIC (or in QUIC in the context of QUIC LB). > > > > - Igor >
