About µTP: congestion Control

[serveh]

Hi guys,

I'm implementing the congestion control mechanism used in µTP (LEDBAT ) and I encountered some problems .

As you know, what LEDBAT uses as a sign of congestion is delay opposed to packet loss in TCP congestion control. So if one_way_delay is more than a TARGET, we consider it as a congestion and decrease our sending rate (congestion window). Here is what LEDBAT specification says:

off_target = TARGET - queuing_delay + random_input()

cwnd += GAIN * off_target / cwnd

# flight_size() is the amount of currently not acked data.

max_allowed_cwnd = ALLOWED_INCREASE + TETHER*flight_size()

cwnd = min(cwnd, max_allowed_cwnd)

And here is the values spec suggests for the parameters:

TARGET = 100;

GAIN = 1.0;

ALLOWED_INCREASE = 1.0;

TETHER = 1.5;

Considering these , if flight_size becomes 0 at some point, max_allowed_cwnd becomes 1.0, so whatever calculated cwnd is, final cwnd would be 1.0(The minimum amount of cwnd while a TCP flow exists!). Even worse , if cwnd becomes 1.0, it remains 1.0 forever. Because cwnd = 1.0 means just send 1 packet. So on receiving ack, flight_size would be 0 and again max_allowed_cwnd would be 1.0 !

Please tell me what's that I'm not considering

[Greg Hazel]

First, I strongly encourage you to use libutp instead of re-implementing uTP. https://github.com/bittorrent/libutp

Second, why would cwnd stay at 1 if it reaches 1? It's always modified by "cwnd += GAIN * off_target / cwnd", which should increase it if the target is not met.

[serveh]

Yes, cwnd should be increased by the formula you mentioned , but since max_allowed_cwnd is remained 1.0 and we take minimum of these two, new cwnd remains 1.0 .

However I found out that there was a bug in the old spec and in the new spec it's fixed, so it does not remain 1.0 and increases.

Thank you for your help.