{'fraction_non_alphanumeric': 0.03595317725752508, 'fraction_numerical': 0.006688963210702341, 'mean_word_length': 5.042929292929293, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
DATE : Distributed Adaptive Traffic Engineering

Congestion in the network causes poor throughput and long delays for end users, and also leads to an inefficient usage of network resources. In the Internet today, end users run the Transmission Control Protocol (TCP) to adapt their sending rates to congestion. Independently, Internet Service Providers (ISPs) monitor their networks for signs of overloaded links and adapt routing to alleviate congestion in a process known as traffic engineering (TE). The current state of the art for TE occurs at the timescale of hours and is centralized [1], [2], [3]. As traffic patterns shift on the order of seconds, a dynamic and distributed TE is an attractive alternative. Yet, previous research on load-sensitive routing [4], [5] has shown that dynamic, distributed routing is prone to instability. More recently, there have been proposals for online multipath traffic engineering, namely MATE [6] and TeXCP [7]. They have both made strides in showing it is possible to achieve stable distributed dynamic traffic engineering. Still, both MATE and TeXCP ignore the congestion control. We propose a distributed adaptive traffic engineering (DATE) algorithm. DATE stands out from previous work by simultaneously satisfying the needs of users and ISPs. Each user wants to maximize their own utility (e.g.a function of throughput or delay) and ISPs want to efficiently use network resources. These needs can be at odds with each other, and DATE aims to balance them. There is an alternative body of work which studies multipath congestion control, as in [8], [9], [10]. Those works are purely theoretical, however, and ignore implementation and deployment issues. The design goals for DATE can be summarized as follows: 1) Distributed: in order to adapt at a small timescale, the algorithm should not require centralized computation or a full network view. 2) Optimal: the algorithm must maximize a weighted sum of user and operators’s objectives. 3) Stable: the algorithm should converge quickly and not have oscillatory behavior. 4) Implementable: only a limited number of changes to a limited number of routers is required. 5) Efficient: the computations should be efficient and not prevent the routers from performing other functions. In the following section, we introduce the notion of consistency price to lead to a distributed gradient algorithm