Home - rohithsaji/TCP-BBRv1 GitHub Wiki

Evaluation of TCP-BBRv1 in Wireless Networks

This project aims to evaluate the performance of TCP-BBRv1 in wireless networks and is done as a part of CS415 Wireless Networks Course.

Introduction of TCP-BBR

TCP BBR (Bottleneck Bandwidth and Round-trip Propagation Time), created by Google and published in late 2016, is a congestion-based congestion control technique. Unlike older algorithms like as CUBIC, which use packet loss as a congestion indicator, BBR analyses congestion by monitoring roundtrip times, resulting in higher, more stable throughput while also lowering latency. It should theoretically be able to run at Kleinrock's optimal operating point of highest delivery rate with the least amount of congestion. This avoids the formation of queues, resulting in the shortest possible time.

Advantages of TCP-BBR

  • It is designed to respond to actual congestion, rather than packet loss. This design enables TCP-BBR to perform better than tradiotional algorithms in wirless and wired-wireless hypbrid networks.

  • Service providers can deploy BBR rapidly on the sender side, as there is no need for client support or intermediate network devices.

  • BBR has shown significant reductions in latency in last-mile networks that connect users to the internet.

Evaluation

1. Goodput Performance

The effective amount of data supplied across the network is known as goodput. It's a clear indicator of how well a network is doing. We anticipate a good TCP scheme to transmit as much data as possible while remaining friendly to other TCP flows in terms of network resource use, such as bandwidth.

. . . . . . . . -> Wireless Link

------- -> Wired Link

n0--------------n1. . . . . . . . . . . .n2------------n3

We use the above network to simulate our results. Data is delivered from the source to the destination using BulkSendHelper with no MaxBytes limit. Simulation was done with the follow configurations:

  • First we simulate the network with a more drastic bottleneck. Setting the wired link data rate as 100Mbps and delay as 1ms. The wireless link has a data rate of 12 Mbps.
  • Second we simulate the network with a less drastic bottleneck. Setting the wires link data rate at 100Mbps and delay as 1ms. But, increasing the wireless link data rate to 24 Mbps.

All the configurations are set with ConstantSpeedPropagationDelayModel and FriisPropagationLossModel. With the above configurations we test the network with different error rates on the Bottleneck link. But, there is no way to directly set a particular error rate for wireless networks in ns3(check here). So to simulate error we have used PostReceptionErrorModel using the attribute ErrorRate.

2. Fairness

The fairness of TCP is another major issue. Multiple connections in the same TCP scheme must work well together and converge to their respective fair shares of resources(Band Width). We use the fairness index function (7) proposed in this paper.

We used the below topology to stipulate the results:

S------T1- - - - wireless bottleneck - - - -T2-------R

T1T2 is defined as T here S and R has 20 senders and 20 recievers respectively with 2Mbps and 10ms The wireless bottleneck has 54Mbps and 100ms(WIFI_STANDARD_80211a)

3. Friendliness

A friendly TCP scheme should be able to coexist with other TCP variants and not cause them starvation.

To verify the friendliness of TCP BBRv1 we use the mixed wired wirless network shown above, where TCP BBRv1 coexsists with TCP Cubic. The wired link has bandwidth of 100Mb/s and 45ms delay, and the wireless link has a bandwidth of 20Mbps and 1 ms delay. There are 20 pairs of connections, in which m are TCP BBRv1 and n are TCP Cubic. The proportion of the TCP schemes in the network are varied by adjusting the values of m and n. Simluation is conducted over a lossy bottleneck link and also a good bottleneck link.

Note:

  • Evaluated performance using the evaluation procedure from this paper .
  • All changes pushed to the master branch.

Team members

  • Rohith Saji: 181CO143
  • Sasidhar Swarangi: 181CO245
  • Akhilesh Lade: 181CO130
⚠️ **GitHub.com Fallback** ⚠️