The May/June issue of acmqueue is out now
Networks
PDF
ITEM not available
Originally published in Queue vol. 10, no. 5—
see this item in the ACM Digital Library
Tweet
Related:
Yonatan Sompolinsky, Aviv Zohar - Bitcoin's Underlying Incentives
The unseen economic forces that govern the Bitcoin protocol
Antony Alappatt - Network Applications Are Interactive
The network era requires new models, with interactions instead of algorithms.
Jacob Loveless - Cache Me If You Can
Building a decentralized web-delivery model
Theo Schlossnagle - Time, but Faster
A computing adventure about time through the looking glass
Comments
(newest first)
Displaying 10 most recent comments. Read the full list hereHere are two resources for current work on the bufferbloat front:
- https://www.bufferbloat.net - the canonical site that collects all our work
- https://lists.bufferbloat.net/listinfo - the Bloat and Codel mailing lists contain our most recent investigations
As noted above, this article was written rather hastily. In http://pollere.net/Pdfdocs/draft-02.pdf we got a chance to provide more explanation of some important features.
Figures 1 and 2 look a lot like tubes with packets moving through them. Is the internet made up of a series of these tubes?
i want simulation code for red,fred,wred and blue algorithms on ns2
@Andrey,
I am trying to see if this works actually, by building a CoDel front for work queueing in Erlang. Currently, I have the code and I am measuring if it works to see what happens.
I don't know if this is the solution for a big problem or not. But when i start reading this article i didn't know what Codel is and now i know everything.
So this is a great article, thank you!
I'm not a scientist, so forgive me my ignorance. I have a crazy idea about this approach application. I believe that in software development we also have an issue of over buffering. In most cases of remote call implementation (i.e. web services) we tend to queue requests one way or another, but rarely reject new requests until the system is completely hosed. The timeout is enforced by abandoning the request if it took more than timeout so far. We don't say to the client: "No, we can't even start processing you request because there is no way we can do it in given time.", instead we hope that somehow we might be able to do it. (which technically is true: in order to make 100% reliable decision about rejection we have to look into the future). I tried to use exponential moving average of request time of past requests time (RTT in network term). It worked fairly well, but has some down sides: requires some knobs, sometimes misses the target, doesn't work well with mix of quick and slow requests, etc. So, I'm wondering if CoDel be applied there? Maybe I'll be able to try it some day, but before that it would be great to hear how it looks from the scientific point of view... Thanks for the great article!
I tried to comment here but the comment was refused.
I don't understand the ruleset being used for comment refusal but I have real comments regarding this article. Contact me if you're interested.
I've given up trying to enter my comment.
No control law is "perfect" and we've looked at lots of variants. We are pleased with how this one works but welcome others' work on improvements.
We have been looking at the "drop elderly packets" approach for a while. It turns out that it only seems to come into play where there are really large output link rate decreases, BUT it means making assumptions about what is "old" so we have not recommended that at this time because we only add something when we are sure it is useful, does no harm, and is worth any complexity added to the implementation.
We were on a very tight deadline to get this article done and I'm sure the language could be improved. However, I was afraid Jim Gettys would show up at my door with a cattle prod if I didn't finish it when promised. I'm sorry the language offends.
The sqrt law is logical for one tcp stream, or multiple streams with packets uniformly distributed through the queue. If you have multiple independent bursty streams, the sqrt law has little reason to work and might cause behavior which will be hard to debug.
Another way you can guarantee that latency will not go high (>100ms, f.e.) for the packets already in the queue by dropping ones that are "very old" (>150ms, f.e.) right away, and then having each incoming packet remove some "old" ones to bring the latency closer to the target.
There might be other ways to do it, but the main point is, while CoDeL is a fine solution, the whole field is not really rocket science, and suffers BADLY from complex wording and lack of metaphorical explanations. Just look at the article above, and the "appendix" which for some reason is not in the links at the end of article. It took LESS amount of words to explain the algorithm (not including C code) than the "high-level explanation" which was for some reason labeled "ONE CODE MODULE, NO KNOBS, ANY LINK RATE" instead of "How it works". Does anyone in the field still speak plain English? And what with the "r.p" and "sojourn_*" variable names in the code? Is this really necessary?.. Would "deque_result.pkt" and "time_in_queue" really be that much harder to write?
Displaying 10 most recent comments. Read the full list here
© 2018 ACM, Inc. All Rights Reserved.