0

I would like to know about the overall latency of the TCP congestion control for adapting to varying network conditions. Specifically, my questions are:

  1. How fast can the system react after a change of available bandwidth and/or roundtrip time (RTT)? By reacting, I mean modifying the send rate to match the new network conditions?
  2. How long does it take for the system to measure a change in the network conditions? As I understand, TCP by default only measures RTT by looking at the sequence numbers in the ACKs. Does it mean that it will take one RTT for the system to react to any changes in the network conditions?
  3. Are there any specific TCP congestion control algorithms developed for low-latency applications? I believe this is going to be important with new generation of applications (e.g. teleoperation, virtual reality) assuming that TCP can be used for such applications. A quick search on recent congestion control algorithms brought me to BBR from Google. However, it seems that the main purpose of BBR is to maximize the TCP throughput by operating closer to the optimal operation point (as defined by Kleinrock). I didn't see any considerations regarding latency in their paper.

Sorry if some questions do not make much sense. Networking newbee here, just starting to learn about the details of TCP congestion control. I would appreciate any help or direction which can help me understand the topic better. Thanks!

Improve this question
3
  • "Are there any specific TCP congestion control algorithms developed for low-latency applications?" Real-time protocols, such as video, VoIP, teleoperations, etc., use UDP. TCP is used for things like file transfers, where missing or out-of-order data cannot be tolerated. The biggest part of latency is serialization delay and distance, and you really cannot do anything about that. The other part of latency is the processing time on the source and destination.
    – Ron Maupin ♦
    Commented Jun 19, 2019 at 17:52
  • There are also various HTTP-based streaming protocols like MPEG-DASH and HLS that are mainly used over TCP. But sure, for real-time video RTP over UDP is probably the way to go, in most cases.
    – chronosynclastic
    Commented Jun 19, 2019 at 20:59
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin ♦
    Commented Dec 15, 2019 at 4:25

1 Answer 1

Reset to default
2

TCP congestion control is far too elaborate to look into detail here. For a start, check out https://en.wikipedia.org/wiki/TCP_congestion_control. Reaction to channel parameters can be as fast as RTT but may be slower, depending on several factors.

Generally, you have to select your transport protocol by your requirements. TCP offers good congestion control, flow control, and guarantees in-order delivery. You have to weigh these benefits against your other requirements.

TCP mechanisms preclude real-time, lowest latency transport - if that is your requirement you need to select another transport protocol, e.g. RTP or RTSP. In extreme, you can use fire-and-forget UDP transport and implement your requirements on top of that, in a sublayer beneath the actual application layer.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.