Project

General

Profile

Actions

Feature #4500

open

Improve congestion detection/marking algorithm

Added by Davide Pesavento almost 7 years ago. Updated about 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Faces
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

The algorithm implemented in #4362 is loosely based on CoDel. However, it differs from CoDel in two important aspects, which limit its effectiveness.

  1. It's based on the queue size in bytes rather than on the packet sojourn time.
  2. 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.


Related issues 1 (0 open1 closed)

Related to NFD - Feature #1624: Design and Implement Congestion ControlClosed

Actions
Actions #1

Updated by Anonymous almost 7 years ago

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.

Actions #2

Updated by Davide Pesavento almost 7 years ago

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.)

Actions #3

Updated by Davide Pesavento about 4 years ago

  • Tags set to needs-discussion
Actions #4

Updated by Davide Pesavento 12 months ago

  • Related to Feature #1624: Design and Implement Congestion Control added
Actions

Also available in: Atom PDF