Google: Difference between revisions
→Networking Followup
Line 174:
*SACK to minimize data that is resent
*Fast re-transmits to reduce delay before resend
Amount of data that can be in transit (flight) in the network▼
Includes data in queues if they contributed to the delay▼
BDP (bytes) = total_available_bandwidth (bps) x round_trip_time (sec) / 8▼
*BIC TCP for faster recovery from packet loss▼
Allows bandwidth probing to be more aggressive initially when the difference from the current window size to the target window size is large, and become less aggressive as the current window size gets closer to the target window size.▼
A unique feature of the protocol is that its increase function is logarithmic; it reduces its increase rate as the window size gets closer to the saturation point.▼
*BIC is optimized for high speed networks with high latency: so-called "long fat networks". ▼
*For these networks, BIC has significant advantage over previous congestion control schemes in correcting for severely underutilized bandwidth.▼
*BIC implements a unique congestion window (cwnd) algorithm. ▼
*This algorithm tries to find the maximum cwnd by searching in three parts: binary search increase, additive increase, and slow start. ▼
*When a network failure occurs, the BIC uses multiplicative decrease in correcting the cwnd.▼
*BIC TCP is implemented and used by default in Linux kernels 2.6.8 and above. ▼
*The default implementation was again changed to CUBIC TCP in the 2.6.19 version. ▼
*CUBIC is an implementation of TCP with an optimized congestion control algorithm for high bandwidth networks with high latency (LFN: long fat networks).▼
*CUBIC TCP is implemented and used by default in Linux kernels 2.6.19 and above, as well as Windows 10 & Windows Servers.▼
*It is a less aggressive and more systematic derivative of BIC TCP, in which the window size is a cubic function of time since the last congestion event, with the inflection point set to the window size prior to the event. ▼
*Because it is a cubic function, there are two components to window growth. ▼
*The first is a concave portion where the window size quickly ramps up to the size before the last congestion event. ▼
*Next is the convex growth where CUBIC probes for more bandwidth, slowly at first then very rapidly. ▼
*CUBIC spends a lot of time at a plateau between the concave and convex growth region which allows the network to stabilize before CUBIC begins looking for more bandwidth.▼
*Another major difference between CUBIC and standard TCP flavors is that it does not rely on the cadence of RTTs to increase the window size.▼
*CUBIC's window size is dependent only on the last congestion event. ▼
*With standard TCP, flows with very short round-trip delay times (RTTs) will receive ACKs faster and therefore have their congestion windows grow faster than other flows with longer RTTs. ▼
*CUBIC allows for more fairness between flows since the window growth is independent of RTT.▼
== SSH to remote server ==
Line 400 ⟶ 439:
== Re-Evaluate the design ==
Room for improvement?
▲== Bandwidth Delay Product ==
▲ Amount of data that can be in transit (flight) in the network
▲ Includes data in queues if they contributed to the delay
▲ BDP (bytes) = total_available_bandwidth (bps) x round_trip_time (sec) / 8
▲== BIC TCP (Binary Increase Congestion control) ==
▲*BIC TCP for faster recovery from packet loss
▲ Allows bandwidth probing to be more aggressive initially when the difference from the current window size to the target window size is large, and become less aggressive as the current window size gets closer to the target window size.
▲ A unique feature of the protocol is that its increase function is logarithmic; it reduces its increase rate as the window size gets closer to the saturation point.
▲*BIC is optimized for high speed networks with high latency: so-called "long fat networks".
▲*For these networks, BIC has significant advantage over previous congestion control schemes in correcting for severely underutilized bandwidth.
▲*BIC implements a unique congestion window (cwnd) algorithm.
▲*This algorithm tries to find the maximum cwnd by searching in three parts: binary search increase, additive increase, and slow start.
▲*When a network failure occurs, the BIC uses multiplicative decrease in correcting the cwnd.
▲*BIC TCP is implemented and used by default in Linux kernels 2.6.8 and above.
▲*The default implementation was again changed to CUBIC TCP in the 2.6.19 version.
▲== CUBIC TCP ==
▲*CUBIC is an implementation of TCP with an optimized congestion control algorithm for high bandwidth networks with high latency (LFN: long fat networks).
▲*CUBIC TCP is implemented and used by default in Linux kernels 2.6.19 and above, as well as Windows 10 & Windows Servers.
▲*It is a less aggressive and more systematic derivative of BIC TCP, in which the window size is a cubic function of time since the last congestion event, with the inflection point set to the window size prior to the event.
▲*Because it is a cubic function, there are two components to window growth.
▲*The first is a concave portion where the window size quickly ramps up to the size before the last congestion event.
▲*Next is the convex growth where CUBIC probes for more bandwidth, slowly at first then very rapidly.
▲*CUBIC spends a lot of time at a plateau between the concave and convex growth region which allows the network to stabilize before CUBIC begins looking for more bandwidth.
▲*Another major difference between CUBIC and standard TCP flavors is that it does not rely on the cadence of RTTs to increase the window size.
▲*CUBIC's window size is dependent only on the last congestion event.
▲*With standard TCP, flows with very short round-trip delay times (RTTs) will receive ACKs faster and therefore have their congestion windows grow faster than other flows with longer RTTs.
▲*CUBIC allows for more fairness between flows since the window growth is independent of RTT.
| |||