3 ms·

Right. I worked on congestion avoidance for a UDP based protocol and it's really difficult to get this right because you have to coexist with lots of other alg

by YZF 10y ago

Right. I worked on congestion avoidance for a UDP based protocol and it's really difficult to get this right because you have to coexist with lots of other algorithms on the same network. If you are "fighting" a loss based algorithm TCP stream it's virtually impossible for you to get your fair share of bandwidth without getting packet loss. An algorithm for efficient local networking where everything is under you control is very different than something that runs of the Internet. Not even sure that this style of congestion avoidance is the best approach for a tightly controlled local network. Edit: and keep in mind that packet loss is correlated with queues filling up. So as long as there's lots of loss based algorithms in the wild it's difficult for someone to come in with a better solution that coexists with those other flavours (at least if you're not allowed to touch the "network" itself).

deleted 10y ago
[deleted]
jamesblonde 10y ago
We are also working on a congestion avoidance for a UDP based protocol - our goal is to share large volumes of data over the Internet but have high throughput for high latency links and support NAT traversal. So no UDT. We're using a varient of LEDBAT (utp/micro-torrent). What are your negative experiences based on?
- YZF 10y ago
  It's not really a negative experience. It's just that it can be difficult. In general I think it's useful to think as the bandwidth of a TCP stream being a function of loss and latency (and connection time, at least initially, less of a factor for long lived active connections). The different variants of TCP have slightly different curves. You want your UDP algorithm to play nice with these otherwise you may use more than your fair share or you'll get hammered by competing TCP streams. Apologies if this is kind of basic :)
StillBored 10y ago
If you are "fighting" a loss based algorithm TCP stream it's virtually impossible for you to get your fair share of bandwidth without getting packet loss. While I agree with the general sentiment, a UDP algorithm matched with a block based FEC, can actually get far more than its "fair share" simply by ignoring the packet loss. Its bad enough, that if your routers aren't deprioritizing UDP traffic you can generally consume really close to 100% of the available bandwidth. Particularly if you pace your packets and pick an algorithm that can handle somewhere in the ballpark of 10-20% packet loss before backing down.
- YZF 10y ago
  Sure but then you're a bad network citizen... That was the point I was trying to make... In your example you're getting the (high) packet loss and error correcting for those but right at the "fair share" point there is loss.

by YZF 10y ago

deleted 10y ago

[deleted]

jamesblonde 10y ago

We are also working on a congestion avoidance for a UDP based protocol - our goal is to share large volumes of data over the Internet but have high throughput for high latency links and support NAT traversal. So no UDT. We're using a varient of LEDBAT (utp/micro-torrent). What are your negative experiences based on?

YZF 10y ago
It's not really a negative experience. It's just that it can be difficult. In general I think it's useful to think as the bandwidth of a TCP stream being a function of loss and latency (and connection time, at least initially, less of a factor for long lived active connections). The different variants of TCP have slightly different curves. You want your UDP algorithm to play nice with these otherwise you may use more than your fair share or you'll get hammered by competing TCP streams. Apologies if this is kind of basic :)

StillBored 10y ago

If you are "fighting" a loss based algorithm TCP stream it's virtually impossible for you to get your fair share of bandwidth without getting packet loss. While I agree with the general sentiment, a UDP algorithm matched with a block based FEC, can actually get far more than its "fair share" simply by ignoring the packet loss. Its bad enough, that if your routers aren't deprioritizing UDP traffic you can generally consume really close to 100% of the available bandwidth. Particularly if you pace your packets and pick an algorithm that can handle somewhere in the ballpark of 10-20% packet loss before backing down.

YZF 10y ago
Sure but then you're a bad network citizen... That was the point I was trying to make... In your example you're getting the (high) packet loss and error correcting for those but right at the "fair share" point there is loss.