[Nfd-dev] [EXT] Congestion marking on testbed

[Junxiao Shi]

Dear folks

Congestion marking by the forwarders and congestion control algorithms in
consumers go hand-in-hand in providing effective congestion control in NDN
network. This scheme is designed in the paper: *A Practical Congestion
Control Scheme for Named Data Networking*
<https://named-data.net/publications/practical_congestion_control_scheme/>
(PCON).

The most important part of the PCON paper is in Section 3.
PCON consists of five components:

   1. Congestion Detection: Each node detects congestion locally by
   monitoring its outgoing queues.
   2. Congestion Signaling: After detecting congestion, nodes mark Data
   packets to inform downstream routers and consumers.
   3. Consumer Rate Adjustment: End consumers react to congestion signals
   by adjusting their Interest sending rate.
   4. Multipath Forwarding: Downstream routers react to congestion signals
   by adjusting their traffic split ratio.
   5. Local Link Loss Detection: On wireless and IP overlay links we
   locally detect packet loss and signal it back using NACKs.


Forwarder's congestion marking feature is item 2 *congestion signaling* in
the PCON framework. It informs consumers about an in-network congestion.
Notice that congestion marks are advisory: the consumer is expected to
react to the congestion marks in consumer rate adjustment feature. If the
consumer does not cooperate, congestion marks would be useless. PCON
framework does not have an enforcement mechanism.

The congestion signaling feature depends on item 1 *congestion detection*.
As intended by the PCON authors, this should be based on sojourn time, i.e.
how long a packet remains in the queue. See RFC8290
<https://tools.ietf.org/html/rfc8290> for background.
Both NFD and NDN-DPDK implemented congestion mark, and the difference is in
how they perform congestion detection.
In NFD (as of v0.7.1), outgoing queues are in the kernel and NFD cannot
measure the sojourn time directly, and congestion detection is based on
send queue length as an approximation. The implementation is in
GenericLinkService::checkCongestionLevel
<https://github.com/named-data/NFD/blob/9ab43e67dbcec8e5c9a1e28007a14d97655a8079/daemon/face/generic-link-service.cpp#L246>
function.
In NDN-DPDK (as of 2020-June), congestion detection is based on sojourn
time, but it's applied to incoming queues instead of outgoing queues,
because the benchmarks indicate that the bottleneck occurs on the input
side. See the NDN-DPDK paper
<https://dl.acm.org/doi/10.1145/3405656.3418715> for explanation.


Congestion control algorithms in consumers is item 3 *consumer rate
adjustment* in the PCON framework.
As mentioned above, having consumers react to congestion marks is required
for PCON to work. Without consumer reaction, the advisory-only congestion
marks are useless.
ndn-cxx SegmentFetcher, ndncatchunks, NDNts @ndn/segmented-object package,
and NDN-DPDK app/fetch package all implement the same algorithm: the basic
congestion control algorithm is CUBIC (RFC8312
<https://tools.ietf.org/html/rfc8312>), while receiving a congestion mark
triggers a window decrease.
Additionally, ndncatchunks can be configured to use AIMD as the basic
algorithm instead of CUBIC, but there isn't much value in doing so.

According to PCON authors, if the forwarders do not insert congestion
marks, the consumer's congestion control algorithm (i.e. CUBIC) is still
useful.
However, it would be less effective, because window decrease would not
happen until after a timeout (i.e. packet loss), which typically occurs
later than congestion marks which is a form of early signaling.


See also #1624 <https://redmine.named-data.net/issues/1624> and its
subtasks for discussions related to the congestion control implementation
in NFD and ndncatchunks, some of which are still incomplete.

Yours, Junxiao


Notice: I generally do not answer technical questions regarding
non-confidential projects in private, because I believe in an open
development procedure in which everyone shall have access to all technical
communications through mailing list archives and issue trackers, etc. The
requester who posted the question below has granted permission for me to
send the question and my reply to the mailing list. The requester did not
post to the mailing list initially because they believed that the question
was merely asking for links to existing information, but I still believe it
is valuable for this answer to be recorded by the mailing list, because
having this question implies that the desired information is not adequately
accessible by searching existing resources, and my answer would become
searchable once posted. Please reply-all to the mailing list to continue
the open discussion.


On Fri, Jan 22, 2021 at 7:17 PM Lixia Zhang <lixia at cs.ucla.edu> wrote:

> *External Email*
> Junxiao, Beichuan, and Alex
>
> Sichen started playing with NDN congestion control (this is for Edmund's
> stuff), one of the first things he's trying to figure out is the interplay
> between congestion marking and catchunk congestion control -- how much is
> the difference between with, and without the marking.
>
> I suggested Sichen to put together a slide deck that describes both. I
> recall a few years back when you people implementing the marking, there
> were some design slides. Wonder if any of you could sender the pointers (or
> even redmine discussions) to Sichen?
>
> thanks, Lixia
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210122/e6075b9d/attachment.html>