Menu
▾
▴
#69 Improve rate control algorithms
udplso uses a rudimentary method of transmit rate control, consisting of sleeps between each packet send, with a statically configured duration calculated from the desired rate. The actual duration of the sleep is somewhat variable, however, resulting in imprecise rate control. As a result, to achieve a particular desired rate, one must configure some higher rate, and the delta between desired/configured rates is variable between machines and workload sizes.
This feature request is for udplso rate control to use a more sophisticated algorithm. For example, a token bucket (http://en.wikipedia.org/wiki/Token_bucket) or a leaky bucket (http://en.wikipedia.org/wiki/Leaky_bucket).
Some additional advice:
For our intended use, the rate control algorithm must not be allowed to induce unacceptable amounts of jitter into competing RTSP streams (IP telephony and video teleconferencing). What this means: To achieve a desired average rate (over some small rolling window of time), you must occasionally transmit at a higher rate to make up for the moments when transmit rates dipped below configured values. The extent and duration of the overshoot should be minimized. For similar software (SWRDFSH), a bucket capacity of one-second's worth of data (i.e., a one-second rolling window) been shown to function well in our environment.
Discussion
Anonymous
There clearly won't be time to address this in version 3.4.0.
An initial implementation of the token bucket algorithm has been implemented in branch: bug-0069-Improve-LTP-RateControl. Further testing will be performed.
Last edit: Jeremy PM 2016-06-23
Addressed in the bug-0069-Improve-LTP-Rate-Control feature branch, per Jeremy Pierce-Mayer.
Last edit: Scott Burleigh 2019-07-08
Jeremy and I have agreed that some more development and (especially) some more testing to demonstrate reduced jitter will be needed before we release this revision, so we are slipping it into version 3.5.1
A little clarification may also be in order. Transmission rate control in udplso is "rudimentary" because its original purpose was simply to slow down UDP transmission enough to reduce UDP congestion loss. When a datagram arrives at a UDP buffer before the current occupant of that buffer has been processed, that earlier datagram is simply lost; this results in otherwise avoidable LTP retransmission and reduces throughput. UDP rate control only needed to be strict enough to force the udplso process to be rescheduled, giving the IP stack an opportunity to deal with UDP buffer contents.
In that sense, the revision proposed in this ticket is not a bug fix but a feature request. UDP rate control is now being asked not only to reduce congestion loss but also to reduce jitter in the rate of datagram arrival, to improve RTS performance on the International Space Station. That is certainly reasonable, but we are going to have to make sure that meeting this new requirement doesn't cause us to fail in the original purpose of the feature.
Jeremy's revisions and testing are not yet finished, so we are slipping this into version 3.6.1.
Nicola Alessi (U. of Bologna) has developed some code that addresses this issue. Josh is working on integrating it into ION.
Nicola will be at JPL in three weeks and can work on this integration himself at that time. Moving it to 3.6.3 in the expectation that it can't be finished in time for the 3.6.2 release, but will bring it back to 3.6.2 if possible.
Nicola's fix for udplso is going into 3.6.2, but this ticket is being left open for two additional closely related work items:
1. The udpclo daemon in bp/udp needs to be updated to work the same as udplso.
2. The transmission rate underlying both udplso and udpclo rate control should be taken from the contact plan rather than provided on the daemon command line.
Addressed in bugs-69-and-138 feature branch.