English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Plus monthly

Global: Zendy Tools annual

Global: Zendy Tools monthly

Global: Zendy Free Plan

Proposals to handle differentiated and guaranteed services in Internet have not provided the benefits that users and operators are expecting. Its complexity, with a large number of interconnected networks, is difficult to handle in an efficient way. This is due to the resource heterogeneity in terms of technologies and the inconsistent implementation of quality of services (QoS) in different networks. Despite several research activities in the area of QoS, Internet is still basically a best-effort network, which it is likely to stay, also in the far future. Streaming-based servers utilizing UDP for the underlying transport need to use some form of congestion control [1] to ensure the stability of Internet as well as the fairness to other flows, like those using TCP. The TCP-Friendly Rate Control (TFRC) is such a congestion control scheme appropriate for UDP. In this paper we target the question of how to optimize network and user-perceived performance in a best-effort network. In particular, we focus on the impact of end-to-end performance of the queue management scheme utilized in a wireless network. The first of the basic assumptions in this study is that the wireless last hop constitutes the bottleneck of the end-to-end (E2E) path. TFRC is intended for applications such as streaming media, where a relatively smooth sending rate is of importance. TFRC measures loss rate by estimating the loss event ratio [2], and uses this measured rate to determine the sending rate in packets per RTT. When a bottleneck is shared with large-packet TCP flows, this has consequences for the rate achievable by TFRC. In particular a low bandwidth small-packet TFRC flow, sharing a bottleneck with high-bandwidth large-packet TCP flows, may be forced to slow down, even though the nominal rate of the TFRC application in bytes per second is less than the total rate of the TCP flows. This is fair only if the network limitation is defined by the number of packets per second, instead of bytes per second. In the TFRC protocol the small-packets are intended for flows that need to send frequent small quantities of information. It intends to support applications better, which should not have their sending rates in bytes per second decreased because of the use of small packets. This is restricted to applications, which do not send packets more often than every 10 ms. The TFRC Small-Packet (TFRC-SP) variant is motivated partly by the approach in Ref. [3], with 6

Adaptive Active Queue Management for TCP Friendly Rate Control (TFRC) Traffic in Heterogeneous Networks