Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Interpreting "Retransmission"?

From: Martin Visser <martinvisser99@xxxxxxxxx>
Date: Tue, 26 May 2009 08:54:39 +1000
rkruz,

I would suspect that all of your your retransmissions are TCP. FTP-Data and GIOP are application protocols that both useTCP for transport. They are expecting TCP to reliablly carry their application payload. Wireshark will always try to show a frame at the highest level possible, so an FTP retransmission for example will in fact be at the TCP level.

 Retransmissions are basically caused when a TCP segment arrives corrupt or does not arrive or is not acknowledged in a timely enough fashion. The TCP process will ask for the segment again. The root cause could be physical errors on the wire/fibre/airwaves, congestion on the network (resulting in drops or delays at routers/switches) or even exhaustion of resources on the client or server preventing it serving the request quick enough. It is your job to find what is likely to be the common cause (possibly through exacibating the situation by loading up the link/server with work to do) and come up with a mitigating strategy.

Regards, Martin

MartinVisser99@xxxxxxxxx


On Mon, May 25, 2009 at 10:29 AM, rkruz <rkruz@xxxxxxx> wrote:
I have a mirrored capture of a simple Ethernet (100BaseT) link as shown
below:
Host > Router/Switch > encryptor> Elec-Optical > Optical-Elec > encryptor >
Routher/switch > Host & separate Mirrored port to WS capture laptop

I see many retransmissions in the Wireshark capture.  Is it fair to say that
the only retransmissions resulting from a link problem would be identified
as TCP protocol?

I see many retransmissions that are identified as "FTP-Data" or "GIOP" for
example.  Are those retransmission probably a result of the application and
not of an issue on the Ethernet links?

Im suspecting that just focusing on the TCP retransmissions is probably a
better indication of any link issues then all non TCP retranmission and is a
more realistic measure of potential link issues.

Any thoughts appreciated.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe