<div dir="ltr">Hi CoDel list.<div><br></div><div>I have implemented the CoDel algorithm in Erlang for a subsystem I am writing. It is one of the "abuse one algorithm in another setting" cases. Here is the implementation, all 200 lines including comments:</div>

<div><br></div><div><a href="https://github.com/jlouis/safetyvalve/blob/master/src/sv_codel.erl">https://github.com/jlouis/safetyvalve/blob/master/src/sv_codel.erl</a></div><div><br></div><div style>One advantage of Erlang is that a lot of the if-maze in the ns2 codel patch can be reduced to a single pattern match here.</div>

<div style><br></div><div>The "safetyvalve" application has a queueing purpose in an Erlang application. Requests arrive at the Erlang system in a rather controlled fashion of Poissonesque proportions (but it isn't Poisson in practice though). In Erlang, we spawn a new (ultra-light-weight) process per incoming request. The problem is that we have limited resources in the system</div>

<div>and we want to protect base service. As soon as a small process begin doing work, it may use a lot of resources, especially memory. We may know the system can at most handle 800 simultaneous requests of a given type. Or that the total amount of connections can't go above 5000. You could just stop providing service when the service ceiling was hit, but this would not allow sudden "spikes" of traffic. This is exactly why we need a queue of incoming requests to "smooth" out request spikes and handle them over time.</div>

<div><br></div><div>The problem, however, is that the queue I use is a tail-drop queue. And I have no idea of the sojourn time through the queue. My fear is that the tail-drop behavior will just incur more latency on the tasks that do get through the queue. Hence the attempt at using CoDel for this.</div>

<div><br></div><div>Preliminary tests show that it does look like it performs the task it should. When the Target is not met for Interval, we begin dropping tasks out of the queue, like we should. More experiments are needed however, before I know if this works well. One thing which is an important difference is that there are no TCP-behaviour where the window will close down upon dropped packets. But CoDel *does* allow me to provide early feedback that the Target can't really be met. For real-time requests, this is actualy the desired behavior.</div>

<div><br></div><div>The next plan is to provide a TCP-like window feature for batch processing of jobs. The idea is that you can have a large list of jobs that needs to be run and have the system be self-tuning. TCP congestion control works, so why not apply it in a new setting :)</div>

<div><br clear="all"><div><br></div>-- <br>J.
</div></div>