|
Bugzilla – Full Text Bug Listing |
| Summary: | Interpretation of RFC 6675 | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | natale.patriciello |
| Component: | tcp | Assignee: | natale.patriciello |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Fixing the bug | ||
Fixed in 13325:e3ce81245b34 |
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.