12
votes

I have a custom UDP protocol with multiple senders/receivers designed to send large files around as fast as possible. It is client/server based.

How can I detect congestion on the LAN to slow the rate of UDP packets being sent?

EDIT: please, no comments on the use of UDP whether it's suitable or not. This protocol uses UDP but reassembles packets into whole files when they arrive.

To rephrase the question: How do congestion control algorithms work and how is congestion detected?

5
I'm voting to close this question as off-topic because it's not programming related.Alnitak
@Alnitak How is it not programming related?Bora M. Alper

5 Answers

15
votes

This is assuming you have to use UDP (TCP would be preferred).

From within the application, the only indication of network congestion is the loss of IP packets. Depending on how you have your protocol, you may want to do something like number each datagram going out, and if a receiver sees that it is missing some (or getting them out of order), send a message (or multiple) to the sender to indicate that there was loss of IP packets and to slow down.

There is a protocol called RTP (Real-time Transport Protocol) that is used in real time streaming applications.

RTP runs over UDP and RTCP(Real-time Transport Control Protocol) working with RTP provides measures for QoS(Quality of Service) like packet loss, delay, jitter, etc to report back to the sender so it knows when to slow down or change codecs.

Not saying you can use RTP, but it may be helpful to look at to see how it works.

4
votes

Latency is a good way to detect congestion. If your latency starts going up, then you should probably slow down. A lost packet is the equivalent to latency = infinity. But you can never be sure if a packet was lost or is just very slow, so you should have a timeout to "detect" lost packets.

3
votes

Flow control is an inherently difficult problem because all you really know is when you sent a packet and when you received a packet. Things like latency, loss, and even speed are all statistics that you have to calculate and interpret.

The following article discusses these statistics and their meaning in depth: DEI Tech Note 0021: Loss, Latency, and Speed

Finding a good solution has been the subject of much research and much commercial endeavor. Different algorithms (TCP, UDT, Multipurpose Transaction Protocol, etc.) use different methods and make different assumptions, all trying to figure out what is going on in the network based on the very sparse data available.

1
votes

I had the following idea:

  • Sender sends the data.
  • Receiver waits a couple of seconds and then calculates the throughput rate / s
  • Receiver sends the rate at which its receiving packets (bytes / s) to sender
  • Sender calculates its rate of sending packets
  • If the rate of sender is significantly higher, reduce it to match receiving rate.

Alternatively, a more advanced approach:

  • Sender starts sending at a predefined min rate (eg. 1kb / s)
  • Receiver sends the calculated receiving rate back to sender.
  • If the receiving rate is the same as sending rate (taking latency into account) increase the rate by a set pct (eg. rate * 2)
  • Keep doing this until the sending rate becomes higher than receiving rate.
  • Keep monitoring the rates to account for changes in bandwidth increase / reduce rate if needed.

Disclaimer: im not network expert, this might not work for you.

0
votes

It seems AIMD algorithm is what they use in TCP and UDT protocols to avoid congestion.

From the Wikipedia page:

The additive-increase/multiplicative-decrease (AIMD) algorithm is a feedback control algorithm best known for its use in TCP Congestion Avoidance. AIMD combines linear growth of the congestion window with an exponential reduction when a congestion takes place. Multiple flows using AIMD congestion control will eventually converge to use equal amounts of a contended link.