Bug 2874

Summary: Interpretation of RFC 6675
Product: ns-3 Reporter: natale.patriciello
Component: tcpAssignee: natale.patriciello
Status: RESOLVED FIXED    
Severity: normal CC: ns-bugs
Priority: P3    
Version: ns-3-dev   
Hardware: All   
OS: All   
Attachments: Fixing the bug

Description natale.patriciello 2018-02-16 10:22:54 UTC
Created attachment 3041 [details]
Fixing the bug

Page 6:

"""
5.   Algorithm Details

   Upon the receipt of any ACK containing SACK information, the
   scoreboard MUST be updated via the Update () routine.

   If the incoming ACK is a cumulative acknowledgment, the TCP MUST
   reset DupAcks to zero.

   If the incoming ACK is a duplicate acknowledgment per the definition
   in Section 2 (regardless of its status as a cumulative
   acknowledgment), and the TCP is not currently in loss recovery, the
   TCP MUST increase DupAcks by one and take the following steps:

   (1) If DupAcks >= DupThresh, go to step (4).

       Note: This check covers the case when a TCP receives SACK
       information for multiple segments smaller than SMSS, which can
       potentially prevent IsLost() (next step) from declaring a segment
       as lost.

   (2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true --
       indicating at least three segments have arrived above the current
       cumulative acknowledgment point, which is taken to indicate loss
       -- go to step (4).
"""

in the point (2), the IsLost (HighACK + 1) check: is the "+1" literal (as 'the next byte') or it means the next segment?

I believe it means the next segment, and this patch fixes in that direction.
Comment 1 natale.patriciello 2018-02-25 05:38:28 UTC
Fixed in 13325:e3ce81245b34