Project

General

Profile

Actions

Feature #4958

open

Implicitly determine remote LpReliability support

Added by Junxiao Shi over 5 years ago. Updated about 4 years ago.

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

0%

Estimated time:
6.00 h

Description

Currently, whether to enable or disable NDNLPv2 reliability on a link requires explicit configuration.
On a link A-B, if A enables reliability and B disables reliability, it would cause A to retransmit every frame several times due to lack of acknowledgement from B.
This in turn causes difficulty in adopting reliability on on-demand faces, because the remote node may or may not support reliability.

To solve this problem, LpReliability module should implicitly determine whether the remote node supports it:

  1. Initially, LpReliability operates in HALF mode: it assigns TxSequenceNumber to every outgoing frame, and acknowledges incoming frames that have TxSequenceNumber header, but does not retransmit potentially lost frames. In HALF mode, local retransmission buffer is unnecessary.
  2. As soon as LpReliability receives an incoming acknowledgement, it concludes that the remote peer supports reliability. Thus, it switches to ACTIVE mode: it also retransmits unacknowledged frames according to existing algorithm.
  3. If LpReliability in ACTIVE mode has not received any acknowledgement for more than 30 seconds, it concludes that the remote peer no longer supports reliability. Thus, it switches back to the previous mode.
  4. LpReliability may optionally support a PASSIVE mode: it acknowledges incoming frames that have TxSequenceNumber header, but does not assign TxSequenceNumber to outgoing frames. This mode can be used instead of HALF for on-demand faces, to avoid overhead of TxSequenceNumber header when the peer does not support reliability.
Actions #1

Updated by Davide Pesavento about 4 years ago

  • Tags set to needs-discussion
Actions

Also available in: Atom PDF