0

As I understand outgoing packets of any transport protocol can be prioritised, but of TCP, UDP, and SCTP, only TCP and SCTP have congestion control allowing their incoming packets to be prioritised as well.

UDP doesn't have any congestion control, so there is no way to tell the source machine of incoming UDP packets to slow down sending them.

So my question is, is it possible to cut UDP connections just before they start to affect the quality of higher-priority connections? If so, what's the best way of setting this up on OpenWrt?

Ideally, downlink congestion should be managed using congestion control when possible, and for UDP connections and connections ignoring congestion control, fallback to rejecting incoming packets for problematic connections for a configurable time (I'd guess a few seconds).

Edit:

The congestion control of SCTP and TCP that I'm referring to is called Explicit Congestion Notification (ECN). I've since realised that it is quite possible that an application ignores or does not properly implement ECN support, so I'd like to extend this question to anything that fails to respond to ECN, which includes UDP. So if my router tells a remote host to “slow down” (via ECN), and that host continues to pump too much data at my ISP, I then want to reject all incoming communication from that host, which, unless it is a DOS attack, should result in a ‘connection refused’ ICMP error and cut the connection. If this isn't enough, then additionally rejecting outbound packets to the host should at least cause a timeout error.

0

UDP doesn't have any congestion control, so there is no way to tell the source machine of incoming UDP packets to slow down sending them.

On the level of UDP, that is true.

So my question is, is it possible to cut UDP connections just before they start to affect the quality of higher-priority connections?

No. Only your ISP can do that. When the packet has arrived at your router, it has already contributed to the congestion and UDP does not tell the source anything, it is completely one-way.

As with OpenWRT, they advertise the limit of their traffic shaping capabilities: OpenWRT Traffic Control

Ideally, downlink congestion should be managed using congestion control when possible, and for UDP connections and connections ignoring congestion control, fallback to rejecting incoming packets for problematic connections for a configurable time (I'd guess a few seconds).

Again, UDP does not tell the source that the packet has been dropped. It just throws packets at your link and doesn't care what sticks.

If you just drop packets and hope for the best:

You may get lucky with the protocols that are built upon UDP. Video streaming, SIP-data etc usually use UDP but are very sensitive to packet loss, detecting it and "hoping" for a chance to optimize their own bandwidth usage.

You may, just as well, have bad luck and trigger retransmits of packets, if the application protocol detects packet loss, but needs those packets be transmitted (bittorrent), it might throw the packets multiple times at your link and congest it even further.

But there are ways to take control of what goes over your link: If you do not know your ISP well enough to let you place a traffic shaping router at their end, you might be able to rent a server on the inet with a fat link and make that your router/gateway, and implement traffic shaping there. With linux, there are tons of howtos to achieve this.

1
  • I think you misunderstand, my intention is not to try to slow down the stream, but to cut it if it is too big. By rejecting all incoming packets, wouldn't this send ICMP messages to the remote host saying that the connection is refused? Please see my edit. As for the remote gateway idea, I think it is a good one that also has other advantages for me, but I'd still like to achieve this solution. Ideally, I'd like my router to learn which hosts have had their connections cut, and send future connections to these hosts via the remote gateway. – James Haigh Dec 5 '13 at 9:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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