Feature #4500
open
Improve congestion detection/marking algorithm
Added by Davide Pesavento about 6 years ago.
Updated over 3 years ago.
Description
The algorithm implemented in #4362 is loosely based on CoDel. However, it differs from CoDel in two important aspects, which limit its effectiveness.
- It's based on the queue size in bytes rather than on the packet sojourn time.
- Packets are marked when they are enqueued rather than dequeued.
This issue is a reminder that we should explore alternative designs to improve congestion control in the forwarder.
The situation is complicated by the fact that the current NFD internal architecture allows very limited control over socket buffers and other queues present in the lower layers. Fully resolving this may require a substantial redesign of NFD's forwarding model, for example adding a queueing layer inside NFD, thus giving control over the dequeue process as well. Such a redesign would also open the door to more advanced features such as #4398.
Well, CoDel is part of the Linux Traffic Control (qdisc). I don't think we can go as low-level with NFD, especially if NFD is supposed to run on multiple platforms.
It's based on the queue size in bytes rather than on the packet sojourn time.
I don't see a way how we could measure the sojourn time like CoDel (adding timestamp during enqueue, reading the timestamp during dequeue).
Do you have a specific design in mind?
Packets are marked when they are enqueued rather than dequeued.
As long as the queues are small enough (i.e. the congestion works as expected), I don't think this is a big problem. Let's say the average queuing delay is 5ms (or 5% of the expected RTT); it doesn't really matter whether the consumers receive the congestion signal 5ms sooner or later.
Klaus Schneider wrote:
I don't see a way how we could measure the sojourn time like CoDel (adding timestamp during enqueue, reading the timestamp during dequeue).
With the current NFD architecture, we can't.
Do you have a specific design in mind?
As I briefly said in the issue description, there could be an explicit queuing layer inside NFD itself, where we could have complete control over the different queues. Something like that will be required by other features as well. But I don't have anything more specific than that in mind. (If it wasn't clear, this is a "wishlist" type of issue, which might never be accomplished. So nothing to do here at the moment.)
- Tags set to needs-discussion
- Related to Feature #1624: Design and Implement Congestion Control added
Also available in: Atom
PDF
Updated by Anonymous 
Updated by