https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14937
--- Comment #5 from Jasper Bongertz <jas...@packet-foo.com> ---
1. Yes, it should not that it's a duplicate ACK to #354
2. "any other ack analysis info required" -> I don't think so. From my point of
view all info is already there
3. "Should there be an additional TCP_A_XXX flag for SACK" -> that would be
nice in general. I have no current use case but my feeling is that there might
be situations where it would be helpful to distinguish between SACK and
non-SACK duplicate ACKs.
4. "Is it possible to define a method to determine a segment is a
retransmission due to SACK?" -> My method would be this (with increasing
difficulty to determine from a-c):
a) the segment fits into the reported SACK range
b) the SACK edges had enough time to actually reach the sender (need iRTT for
this) and inform him about the segment missing
c) the retransmission was sent faster than a FAST Retransmission caused by
three dupe ACKs would have been
I'd be find if we start with a) as a sole reason to call a retransmission a
"SACK triggered retransmission" - it's most likely not incorrect in most
situations.
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
