3

I understand how TCP goes about this - through various methods such as Congestion Window (CWND), Sliding Window, Slow Start and Fast Recovery - it's basically built into the protocol. I understand that when shaping or MSS clamping is applied along the path, TCP can adapt its segment size and transfer rate accordingly.

I also understand that QUIC (which runs over UDP) implements its own version of loss detection and congestion control. QUIC is sort of like a highly-tuned, low-latency, more extensible version of TCP, built for HTTP3, but it can also transport any other application data.

However it's not clear to me how applications - which do not use QUIC - can determine:

  • How many UDP datagrams can be sent at once
  • How large each UDP datagram can be (if PMTUD does not work due to ICMP replies being disabled/blocked by middleboxes)

It's not really clear to me how UDP, being a best effort protocol, doesn't just flood the link/path between the sender and recipient, resulting in significant packet loss.

Or put in other way: How can an application, which needs to send a high volume of data, either statically or dynamically determine the available bandwidth on the path between the sender and receiver, and adjust its datagram size and transfer rate accordingly?*

I understand that RTP has things like RTCP that allow it to limit/increase flow rates or change codecs to reduce/increase packet sizes, for quality control. When running Iperf tests using UDP, you can set the available bandwidth with the "-b" attribute. DNS and DHCP, which use UDP, have comparatively tiny datagram sizes, and will just retry until they receive a response or time out.

*The answer, based on my current understanding, would be: The application would just be designed to use TCP if it needed to send/receive a high volume of data (such as backups or high-definition streaming), and simply wouldn't use UDP unless it also had a supporting out-of-band protocol like RTCP or could be certain of the bandwidth available (i.e. set by the user, like with Iperf).

Improve this question
7
  • Think about game programmers (comes up on Stack Overflow all the time). They typically use UDP for game data to avoid the TCP overhead. A lost UDP datagram for a position move is not a big deal because the next datagram will have the current position. What some programmers incorrectly try is to use the same UDP socket for everything. They should only use it for the game, use TCP for text messaging, and use a different UDP socket for VoIP. They over-complicate the application protocol, thinking they can only have one socket, rather than using three different application protocols to simplify things.
    – Ron Maupin ♦
    Aug 6, 2022 at 14:04
  • Hi Ron. I'm more so wanting to confirm: Do game programmers already know the bandwidth of UDP data their game will use, and can assume that most of their players will have the minimum bandwidth required to transmit/receive this UDP data without unusable amounts of packet loss? eg. "The UDP carrying movement updates etc only uses 100Kb/s of bandwidth, which is likely to always be available on home broadband connections"
    – Inquisitive
    Aug 6, 2022 at 22:32
  • You have no real way to know what the bandwidth of any remote link is. You can only know the bandwidth of any interface connected to your own host, e,g. if you have a 100 Mbps interface, then your bandwidth is 100 Mbps.. You may be able to measure the throughput over the whole path, but you can only know your own bandwidth.
    – Ron Maupin ♦
    Aug 6, 2022 at 22:38
  • Absolutely, however when a programmer needs their app to send data over the internet, I assume they consider its bandwidth requirements (on top of latency/loss constraints) when deciding whether to use UDP or TCP. eg. Netflix understands that they can't guarantee there'll be 15Mbps of bandwidth available to transmit a 4k stream via UDP without significant loss due to congestion. So it seems UDP (without QUIC) is only used for small transactional packets (DNS and DHCP) or streams that have RTCP to monitor loss/jitter and alter the traffic volume by using a different codec.
    – Inquisitive
    Aug 7, 2022 at 0:46
  • "So it seems UDP (without QUIC) is only used for small transactional packets" That is incorrect. Many games use UDP for the game without using QUIC. There are proprietary application-layer protocols, often built in-house, that can adjust for the application. Unfortunately, protocols and applications above OSI layer-4 are off-topic here. Remember, network engineers do not choose the transport protocol used by applications, so the choice of transport protocol is off-topic here. We can help with the theory of transport protocol, but the application or application-layer protocol is off-topic.
    – Ron Maupin ♦
    Aug 7, 2022 at 1:00

2 Answers 2

Reset to default
4

In addition to Steffen's fine answer perhaps more direct replies:

how applications can determine:

  • How many UDP datagrams can be sent at once

They can't. Neither IP nor UDP provide any mechanism to determine that. A host can send UDP datagrams at any rate that its interface(s) allow. An application can exceed that rate as long as the OS's stack can buffer the send requests.

Generally, an application utilizing significant network bandwidth with UDP needs to implement some kind of congestion control on the application layer.

  • How large each UDP datagram can be (if PMTUD does not work due to ICMP replies being disabled/blocked by middleboxes)

Using fragmentation, an application can send UDP datagrams up to an encapsulating IP packet's maximum size (64 KiB).

Without fragmentation and no feedback at all from either the network or the destination, the application can only guess. For IPv4 the minimum guaranteed IP fragment size is just 68 bytes (detailed here). For IPv6 that's 1280 bytes.

Improve this answer
4
  • As stated previously (as linked), the largest packet you should be able to send to any IPv4 endpoint without fragmentation is 576 bytes. That's the smallest MTU allowed in IPv4. (IPv6 is 1280) It's rare for fragmented UDP to make it across the internet. (it's increasingly common to drop TCP fragments as well. Translation: don't break PMTUd)
    – Ricky
    Aug 6, 2022 at 19:50
  • Thank you for your direct answers and providing additional information, Zac, especially that information about the OS' buffer and the min/max datagram sizes. I found a thread that answers my question on how an application would go about congestion control when using UDP stackoverflow.com/questions/8683722/…
    – Inquisitive
    Aug 6, 2022 at 22:13
  • 2
    "Generally, an application utilizing significant network bandwidth with UDP needs to implement some kind of congestion control on the application layer." – Which is what QUIC does (among other things). QUIC is somewhat special in that it is really a transport layer protocol alongside TCP and UDP but has been implemented on top of UDP for backwards-compatibility reasons. Which means that from the perspective of the application layer, it is a transport layer protocol, but from the perspective of the transport layer, it is an application layer protocol.
    – Jörg W Mittag
    Aug 8, 2022 at 5:30
  • 3
    @JörgWMittag Absolutely - I'd generally place QUIC in the transport layer, only that it currently needs to be implemented within an application and rides on top of UDP for NAT compatibility.
    – Zac67 ♦
    Aug 8, 2022 at 6:16
6

UDP does not provide any congestion control, control of packet loss, duplication, reordering ... . All of this has to be implemented at the application level and each protocol might handle this differently based on the specific requirements of the application.

For example with RTP (real time audio or video) it would not help at all to retransmit packets again since it is crucial for user experience that the packets arrive with low latency. Thus the application is designed that packets don't depend on each other too much so that it can simple continue if packets get lost. And with too much packet loss detected (via RTCP) it might simply switch to a different codec or video size so that it needs less bandwidth.

Other UDP based protocols have different requirements, like SIP or DNS simply retransmit the request if they don't get the expected response after some time. VPN like IPSec over UDP, Wireguard or OpenVPN simply ignore any packet loss since the tunnel they provide is simply not to be expected reliable by the users.

If you need reliable data transport with optimal use of available bandwidth then use TCP or a generic protocol with build in congestion control like QUIC.

Improve this answer
3
  • Thank you for your answer. Regarding IPSEC over UDP this is, I believe, actually in order to pass through NAPT gateways and because TCP may induce a "TCP meltdown" on the TCP user data traversing the tunnel.
    – Inquisitive
    Aug 6, 2022 at 22:17
  • 1
    @Inquisitive: A VPN is a tunnel for arbitrary IP traffic. IP is designed to work on top of an unreliable but low latency layer, i.e. packet loss is acceptable but packet delay not . If VPN would provide a reliable transport by dealing with packet loss internally it would come with the cost of packet delay due to retransmits. That's not specific for IPSec over UDP but for all other VPN too. See also Bufferbloat for a similar problem.
    – Steffen Ullrich
    Aug 7, 2022 at 3:58
  • The big problem with TCP is "head of line blocking", if a single packet is dropped from a TCP connection then the packet loss must be detected, the data re-transmitted and the retransmission delivered to the recipient before any subsequent packets can be delivered to the application.
    – Peter Green
    Aug 7, 2022 at 19:13

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.