-
Notifications
You must be signed in to change notification settings - Fork 0
Description
The current code implements a delay between "start cruising" and "start pushing". The delay is expressed in number of bytes acknowledged. The delay is reset after a congestion event. This is debatable. It causes the application experiencing congestion to not only send at a lower rate, but also wait longer before the next probe. We could make the case that the delay should not be reset, so that the application experiencing congestion keeps pushing at regular interval. When two connections compete for a bottleneck, this would ensure that both connections push the other regularly, which would drive a more dynamic equilibrium.
If we do that, we should probably also redefine the delay to be measured either as time elapsed or as number of round trips, because if the application reduces its sending rate, the same number of bytes will take longer to send. A delay based definition would also be friendlier for application-limited connections.