Project

General

Profile

Actions

Bug #3889

open

Retransmission suppression is too aggressive

Added by Anonymous over 7 years ago. Updated over 6 years ago.

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

0%

Estimated time:

Description

The retransmission suppression logic defined in #2377 is supposed to prevent Interest flooding by consumers, caused by either malicious intent or misconfiguration.

However, there is only one bug report mentioning too little suppression of Interests (#3230) and at least four reports reporting too much suppression (#1871, #1913, #1966, #2062)!

This suggests to me that the current retx suppression mechanism is generally too aggressive and should be re-designed.

One specific suggestion I have: Only suppress Interests received from a new incoming face (one that doesn't already exist in the PIT). This allows to aggregate Interests from different consumers without propagating all of them (thus fixes bug #3230), but also propagates Interests coming from the same face, which are most often re-transmissions from the same consumer.

This allows a single consumer to retransmit an Interest as fast as it wants, a potential DoS attack. However, the same consumer can easily start a similar attack by just sending out Interest with a new name, either on the same or on a different prefix. Thus, the retransmission suppression provides no significant protection against intentional DoS attacks.

There may be cases when Interests from the same consumer come in on two different faces (e.g. a consumer sending sequentially on LTE and WiFi). We can discuss a design how to detect and handle these cases below.

Actions #1

Updated by Anonymous over 7 years ago

  • Description updated (diff)
Actions #2

Updated by Junxiao Shi over 7 years ago

  • Subject changed from Current retransmission suppression causes more problems than it solves to Retransmission suppression is too aggresive
  • Category set to Forwarding
  • Start date deleted (12/13/2016)

Original title "Current retransmission suppression causes more problems than it solves" is inaccurate, because before we have #2377, no strategy would permit any kind of retransmission before InterestLifetime expires, which is even more aggressive than today.

Actions #3

Updated by Anonymous over 7 years ago

Agreed.

Another good point: As Junxiao mentioned in today's NFD call, the suppression logic should be completely independent from the Interest lifetime.

Otherwise, we get the perverse incentive of people setting a short Interest lifetime only to allow fast retransmissions. The short lifetime can lead to packets being dropped that are still useful to the consumer, and thus wastes network resources.

Actions #4

Updated by Anonymous over 7 years ago

Another document to support my point is Hila's recent tech report "In-Network Retransmissions in Named Data Networking":

It points out the the current suppression logic requires the application to know about the strategy layer and causes application failures when the strategy layer changes:

In addition, the application has to consider details of the suppression mechanism used by the strategy, if such a mechanism exists. If the strategy does implement a suppression timer algorithm, as in the best-route strategy, the application might face a big challenge. While the details of the strategy may be well known in the application development phase, there is no guarantee that the strategy will maintain the same algorithm in following software versions.

For instance, if the suppression mechanism of the strategy determines that, to avoid suppression, an Interest must be retransmitted X ms after the first attempt, then the application has to follow the requirement and implement its retransmission code blocks and timers according to the X ms requirement. Any strategy modification to this X ms suppression requirement would require a modification in the application code as well. Therefore, the application implementation must be coupled with the strategy design.

Actions #5

Updated by Davide Pesavento over 6 years ago

  • Subject changed from Retransmission suppression is too aggresive to Retransmission suppression is too aggressive
Actions

Also available in: Atom PDF