Project

General

Profile

Actions

Bug #5202

closed

ndncatchunks: window may be decreased more than once per congestion event

Added by Sichen Song over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

When congestion marking is disabled and catchunks with the adaptive pipeline are only relying on timers to detect congestion, it may decrease the window more than once in response to one congestion event.

Its implementation of "conservative window adaptation (CWA)" requires it to "react to only one congestion event (timeout or congestion mark) per RTT." This option does not stop the behavior of consecutive window decrease due to an outstanding interest during one timeout event may trigger another time-out event after one RTT.

Example: segment 1 is sent at time 0s and will be lost. It triggers a timeout event at timepoint 0s+RTO. Segment 100 is sent right before 0s+RTO. Segment 100 is later lost and will trigger a timeout at 0s+2RTO. CWA requires any timeout event before 0s+RTO+RTT not to trigger a window decrease. As RTO>RTT, segment 100 will successfully trigger a second window decrease. However, segment 100 is sent out before adaptation of the previous congestion event. Thus, it should not trigger a window adaptation as the effect of the previous window adaptation is not observed yet.

Solution: Disqualifying outstanding segments during a window decrease from triggering another window decrease.

Actions #1

Updated by Davide Pesavento over 2 years ago

  • Subject changed from Catchunks consecutive window decrease under one congestion event, if only using packet loss as congestion signal to ndncatchunks: window may be decreased more than once per congestion event
  • Start date deleted (05/01/2022)
Actions #2

Updated by Davide Pesavento over 2 years ago

Sichen, if I understand correctly, the congestion mark handling still uses m_highData. Can you explain why the difference?

Actions #3

Updated by Sichen Song over 2 years ago

The identified issue is limited to the case of using retransmission timer to detect loss. The symptom is "reducing window again before observing the effectiveness of previous window size decrease." The cause of this issue is related to RTO >> RTT.

In the case of congestion mark, thers's no overestimated retransmission timer at forwarders (that determines congestion marks). The reaction time from congestion start to congestion being addressed is exactly 1RTT thanks to explicit notification. When a data with congestion mark arrived, every outstanding packet should arrive in one RTT. Thus the existing usage of m_highData is in theory not causing any problem. I believe in this case, requiring "at most one window decrease per RTT" is the same as "requiring all outstanding packets during window decrease to be disqualified from causing another window decreaase."

Thus I'm not making the change to the congestion marking case.

Actions #4

Updated by Davide Pesavento over 2 years ago

  • Status changed from New to Code review
  • % Done changed from 0 to 50
Actions #5

Updated by Davide Pesavento over 2 years ago

  • Status changed from Code review to Closed
  • % Done changed from 50 to 100
Actions

Also available in: Atom PDF