skip to content

Since UDP has no congestion control, who must provide it when an application sends bulk data over UDP, and what does RFC 8085 expect?

level: seniorimportance: should knowfreq 24%

answer

  1. the application, not the transport
  2. collapse and fairness
  3. BCP 145
  4. TCP-fair within an order of magnitude
  5. one datagram per RTT when small

basics

~20 s

The application must. RFC 8085 (BCP 145) says a UDP sender SHOULD control its rate to each destination; bulk senders SHOULD use TFRC or TCP-like window control, or at least compete fairly with TCP within an order of magnitude.

solid answer

~50 s

UDP adds nothing between the application and the network, so congestion control is the application's job. RFC 8085 — the UDP usage guidelines, BCP 145 — gives two reasons it matters: preventing **congestion collapse** and sharing capacity **fairly**. Its first recommendation is to use an IETF transport that already does this, such as TCP, SCTP or DCCP. If you stay on UDP, you SHOULD control the rate of all traffic to a destination, aggregated across sockets and processes. Bulk senders — more than a few datagrams per RTT — SHOULD implement TFRC or window-based TCP-like control, or otherwise compete fairly with TCP within an order of magnitude. Low data-volume senders SHOULD average no more than one datagram per RTT, and retransmissions count as traffic too. QUIC is the modern example: it runs over UDP (RFC 9000) and carries its own loss detection and congestion control.

go deeper

for a junior

Recall that UDP has no congestion control, so an application sending a lot of UDP must limit its own rate.

for a middle

Explain the difference between flow control, which protects the receiver, and congestion control, which protects the path and the flows sharing it.

for a senior

Cite RFC 8085's classes — bulk, low data-volume, no return traffic — with their rate rules, and show that retransmissions fall under the same control.

for a principal

Argue build versus adopt: an in-house scheme must be TCP-fair and carry a circuit breaker, which usually makes an existing congestion-controlled transport the better call.

## Congestion control is not flow control The two are often confused, and UDP has neither. | | Flow control | Congestion control | |---|---|---| | Protects | the receiver | the network path and the other flows on it | | Signal | the receiver says how much it can take | loss, delay or ECN marks on the path | | TCP mechanism | the advertised receive window | the congestion window (RFC 5681 and successors) | | UDP | none | none | A UDP application with a fast receiver can still overload a shared link; congestion control is about the path, not the peer. ## Why UDP's silence is dangerous RFC 8085 §1 gives the two reasons congestion control is critical for the Internet: 1. **Preventing congestion collapse** — a state where more offered load produces *less* useful work, because the network spends its capacity carrying packets that are dropped further along. 2. **Fairness** — letting flows share a path's capacity reasonably equitably. TCP senders back off when they see loss. A UDP sender that does not will keep its rate while TCP flows around it shrink, taking capacity they give up. Because UDP itself provides no congestion control, RFC 8085 says it is up to the applications that use it to prevent collapse and establish fairness. ## What RFC 8085 asks for RFC 8085 is a **Best Current Practice** (BCP 145, obsoleting RFC 5405), and its requirements here are mostly **SHOULD**, not MUST. Its first recommendation is not to build this at all: using an IETF transport such as TCP, SCTP or DCCP is the RECOMMENDED alternative. For applications that stay on UDP, §3.1 says the application SHOULD control the rate at which it sends to a destination, over **all** its traffic to that destination — several processes or sockets count as one aggregate. Then it depends on the application's shape: | Application class | Guideline | |---|---| | **Bulk transfer** — more than a few datagrams per RTT | SHOULD implement TFRC (TCP-Friendly Rate Control), window-based TCP-like control, or otherwise comply with congestion-control principles; if neither TFRC nor windowing, compete fairly with TCP **within an order of magnitude** (§3.1.2) | | **Low data-volume**, can estimate RTT | SHOULD average no more than **one datagram per RTT** to a destination and keep an RTT estimate (§3.1.3) | | Low data-volume, too little traffic for an RTT estimate but can see losses | MAY use a fixed interval that backs off exponentially on loss; **1 second** is RECOMMENDED as the initial value, matching TCP's RFC 6298 (§3.1.3) | | Low data-volume with **no return traffic** | SHOULD NOT send more than one datagram every **3 seconds** (§3.1.3) | | Bidirectional request-response | both directions SHOULD be congestion controlled (§3.1.4) | | No congestion control at all | SHOULD implement a transport **circuit breaker** on the general Internet (§3.1.10) | Running with no congestion control over reserved capacity is described as possibly acceptable in restricted environments but "by no means a safe practice" on the wider Internet; such a mode SHOULD NOT be the default. ## Retransmissions are traffic too An application that adds reliability by retransmitting can make congestion worse: loss is often the *symptom* of congestion, and resending faster adds load exactly when the path has none to spare. RFC 8085 §3.3 is explicit that any application using retransmission is responsible for congestion control of its retransmissions as well as its original traffic, and §3.1.1's timer guidance applies to those retransmission timers. ## Ways to meet the obligation 1. **Use a congestion-controlled transport** — TCP, SCTP or DCCP — when their semantics fit; this is RFC 8085's recommended path. 2. **Use a UDP-based transport that brings its own controller.** QUIC (RFC 9000) runs over UDP, and its loss detection and congestion control live in QUIC itself rather than in TCP. 3. **Implement a TCP-friendly scheme** such as TFRC, or window-based TCP-like control, and design the application around it from the start — RFC 8085 stresses that congestion control is not an add-on to a finished application. 4. **Add a circuit breaker** as the last resort: a mechanism that estimates the congestion a flow causes and stops or sharply reduces it when that congestion is excessive. The interview point is ownership. "UDP is fast because it has no congestion control" is only half an answer; the other half is that the application now owns what TCP would have done, and the IETF's guidance says how much.

  • An application sends only an occasional small query over UDP. Does it need congestion control?
    Less machinery, but not none. RFC 8085 §3.1.3 says low data-volume applications SHOULD average no more than one datagram per RTT to a destination and keep an RTT estimate. If they cannot estimate RTT but can see losses, they may use a fixed interval that backs off exponentially, starting at 1 second. With no return traffic at all, the guideline is at most one datagram every 3 seconds.
  • What is a transport circuit breaker, and when does RFC 8085 want one?
    A last-resort mechanism that estimates the congestion a flow causes and terminates it, or significantly reduces its rate, when congestion is excessive. RFC 8085 §3.1.10 says applications on the general Internet SHOULD implement one if they do not implement congestion control or operate a low data-volume service. It is a safety net against collapse, not a substitute for congestion control.

saying these in an interview costs you the question

  • Routers apply congestion control to UDP, so the application need not.
  • Congestion control is a TCP concern; UDP applications are exempt by design.
  • Flow control and congestion control are the same thing under two names.
  • Retransmitting lost UDP datagrams faster helps a congested path recover.
  • RFC 8085 makes congestion control a MUST for every UDP application.