[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	8614
Summary	Add support for tcp.analysis.spurious_retransmission to TCP dissector
Classification	Unclassified
Product	Wireshark
Version	SVN
Hardware	x86
OS	Linux (other)
Status	UNCONFIRMED
Severity	Normal
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	joe@qacafe.com

Created attachment 10691 [details]
Patch that adds tcp.analysis.spurious_retransmission support

Build Information:
Created patch against trunk-1.8 
joe@cooley:~/lab2/wireshark-1.8-trunk/trunk-1.8$ svn info
Path: .
URL: http://anonsvn.wireshark.org/wireshark/trunk-1.8
Repository Root: http://anonsvn.wireshark.org/wireshark
Repository UUID: f5534014-38df-0310-8fa8-9805f1628bb7
Revision: 49090
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 49081
Last Changed Date: 2013-04-28 11:04:17 -0400 (Sun, 28 Apr 2013)

--
The attached patch adds support for a new TCP display filter
"tcp.analysis.spurious_retransmission". 

Although RFC 793 does not define spurious TCP retransmissions, TCP spurious
retransmissions are referenced in other RFCs and research.


>From TCP/IP Illustrated Vol 1.

====
14.7. Spurious Timeouts and Retransmissions

Under a number of circumstances, TCP may initiate a retransmission even when no
data has been lost. Such undesirable retransmissions are called spurious
retransmissions and are caused by spurious timeouts (timeouts firing too early)
and other reasons such as packet reordering, packet duplication, or lost ACKs.
Spurious timeouts can occur when the real RTT has recently increased
significantly, beyond the RTO. This happens more frequently in environments
where lower-layer protocols have widely varying performance (e.g., wireless)
and was a concern mentioned in [KP87]. Here we focus primarily on spurious
retransmissions caused by spurious timeouts. The effects of reordering and
duplication on TCP are deferred until the following section.
====

The general idea is to detect packets that do not contain any new data. They
may be valid, but in some cases they may indiciate sub optimal behavior and
ultimately wasted bandwidth.

This patch adds display filter support to detect packets that may be
"spurious". Similar to the current tcp.analysis.fast_retransmission behavior,
if a packet is consider spurious_retransmission, it will also be consider the
general "retransmission".

Here is link to a capture file that contains a high number of "spurious"
retransmissions.  

https://www.cloudshark.org/captures/3e24a14eabc1

---

      You are receiving this mail because:

• You are watching all bug changes.