In the field of connection-oriented transports, kernel-space implementations implied that every application executed by the operating system had to use the same congestion control algorithm. With user-space implementations of connection-oriented transports such as QUIC, the Web platform has gained the untapped potential, of selecting the congestion control algorithm that is best matching the application needs. QUIC itself is designed to support pluggable congestion controls. Besides the emergence of BBR and L4S shows a significant trend in the design of low-latency and very low-latency congestion control for connection oriented transports.
A limited capability in selecting the congestion control according to the application need do exist in the Web platform: WebRTC applications are using an RMCAT congestion control for their RTP sessions which is different than the congestion control used by connection-oriented sessions (Datachannel, Websockets, HTTP transactions). In this case, the selection of the congestion control is implied by the selection of the transport protocol (RTP vs connection-oriented).
We argue that it would be beneficial to extend the choice of the congestion control algorithm to connection-oriented sessions of web applications.
Typically, interactive web sessions would prefer to use a congestion control limiting its self-induced latency while background web flows would prefer to use a congestion control maximizing the volume of data transferred in the background with relaxed requirements on transfer delays and a fallback behavior in presence of interactive traffic. The actual applications trade-offs maybe actually be gradual: WebVR applications maybe ready to further sacrifice its network utilization for lowering its latency while web browsing and video streaming maybe willing to achieve different trade-off levels.
On the other hand, cellular networks are known for their link capacity variations. Due to the nature of upcoming 5G radio these capacity variations are anticipated to amplify in the future. When a capacity increase is suddenly available, the data queued up in the base station can be opportunistically transmitted. These transmission opportunities are determined by the radio scheduler whose periodicity is on the ms time frame and even below that figure in 5G. Thus large standing queues are useful to maximize network utilization (exploit transmission opportunities as much as possible). However, they are detrimental to interactivity and low-latency objectives.
If cellular networks had simple means of determining "how much" an application flow wants to trade network utilization for low-delay (e.g. application flows with more or less stringent delay requirements) or the opposite (e.g. background web traffic, pre-fetching of web resources...) there would be an opportunity for networks to contribute to the optimization of the quality of experience while optimizing network utilization.
The usage of multi-path transport layers (i.e. MP-TCP) has developed over the last years. The motivations and the ways applications use multi-path transport are diverse: some are primarily seeking a more reliable connectivity; some are seeking increased network bandwidth while others are seeking a more efficient selection of the network path that is best matching the application needs.
These capabilities are today not available to Web applications and we argue that it would be beneficial to allow web applications to to leverage these capabilities according to their needs.
On the other hand, similar application stakes do exist at the radio carrier level: an application might be interested to use a single long carrier to save on energy; it might be interested to use several carriers to increase the reliability of its connectivity or it might be willing to aggregate the capacity of several carriers to maximize its throughput.
Without application hints, the network will have difficulties in making the best decisions on carrier usage as already shown by the difficulty in setting a relevant secondary carrier threshold for carrier aggregation.
Radio environment maps are expected to emerge in 5G network. Combined with terminal movement predictions its is therefore conceivable to predict the possible radio link capacity in the near future.
If done right, sharing that knowledge would be valuable to both the application and the network: applications would be able to take into account expected future link capacity in their rate adaptation algorithms while the network could expect applications to decrease traffic pressure in the regions where radio link capacities are weaker (e.g. by pre-fetching resources where radio link capacity is abundant and before the terminal crosses a region where it is less abundant).
As we have seen, for a network operator optimizing the quality experienced by its users is not only a matter of providing ever more bandwidth: its also a question of setting the best trade-offs between the parameters it can control (e.g. scheduling policies, queuing policies, carrier selection... and install more capacity when needed) in order to maximize the quality of the applications producing/consuming the traffic mix it serves.
A blind network, i.e. a network that can not observe the application performance metrics induced by the network characteristics is deprived of its operational dashboard.
Today, the web platform already exhibits useful application performance metrics (e.g. WebRTC getStats; Network Error Logging...) to application developers but not to network operators. Such application performance metrics are already proving useful to the automation of network operations (e.g. see Google's Espresso for instance).
With the generalized encryption of application and transport protocols, network operators can not observe the performance characteristics that are useful to network operations.
Generalized encryption is often motivated by privacy protection considerations and by retaining control over precious data.
We argue that the latter argument raise openness issues while the former could be managed with the help of the web platform in various ways: e.g. Browsers could handle the anonymization of application performance metrics (e.g. in a decentralized fashion with browser interoperability; in a centralized fashion by the browser editors...).