Date: Fri, 09 Oct 2015 19:32:05 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 203663] [tcp] Incorrect dupack processing to detect loss Message-ID: <bug-203663-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203663 Bug ID: 203663 Summary: [tcp] Incorrect dupack processing to detect loss Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: hiren@FreeBSD.org Quoting Randall: "When we recognize a dup-ack we *will not* recognize it if for example if the rwnd changes even if new SACK information is reported in the sack blocks. This is due to the fact that in non-SACK you don't (on purpose) recognize ACK?s where the window changed (since you can?t really tell if its a plain window update or a dup-ack).. This means we occasionally miss out on stroking the dup-ack counter and getting out of recovery...." Another report of the same/similar problem: https://lists.freebsd.org/pipermail/freebsd-net/2015-September/043387.html This bug leads to us detecting loss later than we should have. And that leads to suboptimal loss recovery as a whole. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-203663-8>