1

I'm reading Computer Networking: A Top-Down Approach, and from what I understand, UDP has no widely adopted mechanism for congestion control like TCP does. Isn't this a problem for the Internet as a whole, considering that the upcoming HTTP/3 is based on UDP?

I found DCCP, but it is not widely adopted.

And I know congestion control can be implemented in the application layer, but why would an individual choose to do that, if no one is required to? Congestion control seems like something that is good for everyone if everyone does it. But it is not required, and it seems that a few people doing it on their own only results in their application being slower without any noticeable benefit to the Internet, if everyone else doesn't care about congestion control because they just want the highest speeds for themselves individually... which results in a slower Internet for all. This seems like it will be a problem as UDP is more widely used in the future.

Am I off in my understanding of this?

Improve this question
10
  • Actually, a lot of streaming is TCP.
    – Ron Trunk
    May 6, 2021 at 18:38
  • @RonTrunk Thanks for the correction! I was confusing live streaming video, with streaming video in general. I've edited out my incorrect remark on streaming video using UDP.
    – fpsvogel
    May 6, 2021 at 18:48
  • 1
    "in fact my application will be slower with congestion control, than without it. Not necessarily. Having to resend more without congestion control can slow your application much more than using congestion control. "if it's optional for everyone, wouldn't everyone naturally just not do it, unless they came to some agreement that forced everyone to do it?" Again, no. It may sometimes be advantageous to not use congestion control, e.g. real-time data, but in those cases you do not want to resend lost data.
    – Ron Maupin ♦
    May 6, 2021 at 21:05
  • 1
    That's what a lot of programmers on Stack Overflow simply do not get, and they want to use UDP (they are under the wrong assumption that data latency is much worse on TCP, even though it really is not; sending a data packet from one host to another has the same latency, it is just the overhead of setting up a TCP connection that takes time), so they try to recreate TCP without really understanding, and it does not go well for them. The many network-savvy programmers there tell them to just use TCP.
    – Ron Maupin ♦
    May 6, 2021 at 22:21
  • 1
    TCP has a couple of major issues one is head of line blocking, one lost packet means everything gets delayed until it's resent. The other is that switching to a different internet connection breaks ongoing sessions. There have been attempts to fix these issues at the transport layer but they have proved difficul to deploy in practice. This is why application level soloutions based on UDP are rising in popularity.
    – Peter Green
    Feb 15 at 20:52

1 Answer 1

Reset to default
2

UDP is unreliable and has no guarantees. If you use UDP and want reliability or guarantees, then you must add any reliability or guarantees in the application or application-layer protocol.

Real-time protocols, such as VoIP or video do not want missing data to be resent because it would arrive after it is useful. Such applications and protocols are designed to deal with missing data (to some degree before erroring or timing out). If you can buffer on the end-host (non-real-time), you can use TCP because of the buffer, which is how much video is done.

Edit:

TCP congestion control is completely determined and handled by the sender based on the fact that it must resend data. Adding reliability to an application or application-layer protocol can also be used for congestion control the same way that TCP does it, or in some other fashion. For example, QUIC (an application-layer protocol on top of UDP) has flow control, and the intention is to improve congestion control and add things like FEC.

Unfortunately, until we move to IPv6, we are stuck with only TCP and UDP because of NAPT. Other protocols, such as DCCP or SCTP or other future protocols, are not supported by NAPT.

Improve this answer
0

Your Answer

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

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