Re: Packet loss

[Simone Ferlin-Oliveira <ferlin () simula no>]

Thanks Jim,

I am exactly in this point trying to distinguish between retransmission
from packet out of order from actual packet loss on
the link. I knew about this possible misidentification from wireshark
concerning retransmission. Somebody in the forum
posted a possible combination of retransmission followed by lost_segment to
identify actual packet losses.

One of the flows I am analyzing is from a network that has big buffers and
I get lots of retransmissions at the sender that
are not real packet losses caused by the link quality.




On 31 August 2013 20:40, Jim Aragon <Jim () agdatasystems com> wrote:

>  At 10:47 AM 8/30/2013, you wrote:
>
> I am investigating several TCP flows and I am wondering how you can proper
> filter packet loss in tshark/wireshark:
>
> In the forum someone says that the correct way of filtering lost packets
> and looking for tcp.analysis.lost_segments followed by
> tcp.analysis.retransmissions. What about tcp.analysis.ack_lost_segments?
>
>
> I would simply filter on tcp.analysis.retransmissions. This will show you
> all packets that Wireshark identifies as retransmissions. However, be aware
> that Wireshark can mis-identify retransmissions. If there is a gap in the
> sequence numbers, Wireshark will identify any packet that shows up within 3
> ms of when it should have as out-of order, and any packet that shows up
> more than 3 ms after it should have as a retransmission. This 3 ms value is
> arbitrary. If an out-of-order packet is delayed by more than 3 ms, it will
> be identified as a retransmission. A genuine retransmission should take one
> Round Trip Time, or a little more, after the original packet should have
> been seen.
>
> If a packet has been correctly identified as a retransmission and there
> really has been packet loss somewhere along the path, the original packet
> might still be present in your trace file if the point of packet loss is
> downstream from your capture point. Because of this, retransmissions are
> not always preceded by tcp.analysis.lost_segments.
>
>
>
> I have both client and server trace files. When I use the filters above, I
> see slight different values at client and server.
>
>
> Yes, because packet loss occurred somewhere between the client and the
> server. If you capture on both the sender and the receiver, the capture at
> the sender should show all the original packets and all the
> retransmissions. The capture at the receiver will not show the original
> packets that were lost along the way, only the retransmissions.
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe