BBR

Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van

doi:10.1145/3009824

Cited by 421 publications

(35 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We define this available bandwidth as BtlBw, i.e., bottleneck bandwidth. BtlBw can be measured in network stack [3], however, we have to adopt a packet-based approach that is similar but somehow more challenging, since the application behavior and the congestion control status are invisible to us.…”

Section: Btlbw Estimatormentioning

confidence: 99%

“…The ratio of the two is the delivery rate. After obtaining a stream of delivery rate samples, we use a windowed maximum filter to estimate BtlBw, which is similar to [3], but our window is flight-based rather than time-based. We explain how to separate packets into flights in detail in later subsections.…”

Section: Btlbw Estimatormentioning

confidence: 99%

“…After obtaining a stream of RTT samples, we use a windowed minimal filter to estimate RTprop, which is similar to [3]. On the arrival of each ACK at time T, we define:…”

Section: Rtprop Estimatormentioning

confidence: 99%

“…As a result, a temporary form of deadlock may occur due to the interaction between the Nagle's algorithm and delayed acknowledgments. However, even with perfect interaction between application and network stack, TCP's congestion control may still fail to fully utilize network bandwidth [1,3]. More importantly, to validate EVA's performance.…”

Section: Introductionmentioning

confidence: 99%

“…by inferring end-hosts' congestion control status. Such approach may fail for two reasons: First, today TCP's loss-based congestion control, even with the current best of breed, Cubic [5], experience pool performance in some scenarios [3]. Second, one congestion control algorithm may work quite differently from another, e.g., loss-based Cubic and delay-based Vegas.…”

mentioning

confidence: 99%

See 4 more Smart Citations

Network Measurement and Performance Analysis at Server Side

2018

View full text Add to dashboard Cite

Network performance diagnostics is an important topic that has been studied since the Internet was invented. However, it remains a challenging task, while the network evolves and becomes more and more complicated over time. One of the main challenges is that all network components (e.g., senders, receivers, and relay nodes) make decision based only on local information and they are all likely to be performance bottlenecks. Although Software Defined Networking (SDN) proposes to embrace a centralize network intelligence for a better control, the cost to collect complete network states in packet level is not affordable in terms of collection latency, bandwidth, and processing power. With the emergence of the new types of networks (e.g., Internet of Everything, Mission-Critical Control, data-intensive mobile apps, etc.), the network demands are getting more diverse. It is critical to provide finer granularity and real-time diagnostics to serve various demands. In this paper, we present EVA, a network performance analysis tool that guides developers and network operators to fix problems in a timely manner. EVA passively collects packet traces near the server (hypervisor, NIC, or top-of-rack switch), and pinpoints the location of the performance bottleneck (sender, network, or receiver). EVA works without detailed knowledge of application or network stack and is therefore easy to deploy. We use three types of real-world network datasets and perform trace-driven experiments to demonstrate EVA's accuracy and generality. We also present the problems observed in these datasets by applying EVA.Future Internet 2018, 10, 67 2 of 18 today's network applications adopt multi-tier architectures, which consist of user-facing front-end (e.g., reverse proxy and load balancer) and IO/CPU-intensive back-end (e.g., database query). Problems with any of these components can affect user-perceived performance. Developers sometimes blame "the network" for problems they cannot diagnose; in turn, the network operators blame the developers if the network shows no signs of equipment failure or persistent congestion. As a result, identifying the entity responsible for poor performance is often the most time-consuming and expensive part of failure detection and can take from an hour to days in data centers [4]. Fortunately, once the location of the problem is correctly identified, specialized tools within that component can pinpoint and fix the problem.Existing solutions such as fine-grain packet monitoring or profiling of the end-host network stack almost all work under the assumption that the TCP congestion control is not the one to blame. Furthermore, nearly all packet monitoring tools measure the network conditions (congestion, available bandwidth, etc.) by inferring end-hosts' congestion control status. Such approach may fail for two reasons: First, today TCP's loss-based congestion control, even with the current best of breed, Cubic [5], experience pool performance in some scenarios [3]. Second, one congestion control algorithm may work qu...

show abstract

Section: Btlbw Estimatormentioning

confidence: 99%

Section: Btlbw Estimatormentioning

confidence: 99%

“…After obtaining a stream of RTT samples, we use a windowed minimal filter to estimate RTprop, which is similar to [3]. On the arrival of each ACK at time T, we define:…”

Section: Rtprop Estimatormentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

mentioning

confidence: 99%

See 3 more Smart Citations

Network Measurement and Performance Analysis at Server Side

2018

View full text Add to dashboard Cite

show abstract

References

2020

Network Traffic Engineering

View full text Add to dashboard Cite

Appropriate buffer sizes for Internet nodal devices: A networks' topologies–based solution

Eyinagho

Falaki

2020

Int J Communication

View full text Add to dashboard Cite

Summary Switched networks' (including the Internet) nodal devices require buffers to hold packets during periods of congestion and when traffic streams on more than one input port need to access the same output port. Appropriately sizing the buffers has been a contentious issue among researchers over the last couple of years. Three main buffer sizing formulas have been reported in literature, which are: bandwidth‐delay product or BDP, small buffer, and the tiny buffer formulas. But researchers are largely agreed that the BDP formula results in unrealistically large and wasteful buffers, while a number of researchers have held with good reasons, that the small and tiny buffer formulas are theoretical formulations that cannot be generally and practically applied to real networks. Some researchers have even asserted that deriving a single, universal formula for sizing buffers may not be possible. The main purpose of this paper is to explain an approach, which we term “network topology point –of –view,” that we developed to derive a novel, empirical, generic, practical, easy‐to‐apply, closed‐form formula that can be used to obtain the buffer capacity that is optimal—in terms of the minimum capacity possible for lossless operation, for any switched network node, including nodes (switches and routers) in the Internet. The results obtained from utilizing the formula to specify typical nodal buffers' capacities are largely in agreement with the values of the tiny buffer formula in literature; but this paper's formula additionally specifies what we term “very tiny buffers.” The simple approach adopted for presenting this paper makes it a handy tutorial material that explains this “network topology point‐of‐view” concept.

show abstract

BBR

Abstract: Measuring bottleneck bandwidth and round-trip propagation time.

Cited by 421 publications

References 12 publications

Network Measurement and Performance Analysis at Server Side

Network Measurement and Performance Analysis at Server Side

References

Appropriate buffer sizes for Internet nodal devices: A networks' topologies–based solution

Contact Info

Product

Resources

About