Wireshark notes - 2

Expert Info Messages

Previous Segment not Captured

tcp.analysis.lost_segment

Packet loss recovery method #1 - Fast Recovery
If the receiver supports Fast Recovery and notices the jump in sequence number value, it will immediately begin sending Duplicate Acknowledgments requesting sequence number 7,920. Upon receipt of 4 identical ACK (can be more than 4), sender retransmit the packet.

Packet loss recovery method #2 - Sender Retransmission Timeout (RTO)

If the sender notices that a data packet has not been acknowledged within its Retransmission Timeout (RTO) timer value, it will retransmit the packet.

To determine how many packets were lost, add 3 colums - sequence number, next sequence number and acknowledgement number.

Location of the capture

Since we know the sequence number of the packet that is missing, we can use that information to

determine if we see the original and the Retransmission or just the Retransmission. That will tell us if

we are upstream or downstream from packet loss. Filter tcp.seq==9164761.

Duplicate ACKs

tcp.analysis.duplicate_ack Duplicate ACKs are an indication that a host supports Fast Recovery and noticed that a packet arrived with a sequence number beyond the calculated next sequence number. Duplicate ACKs are usually a sign of packet loss, but Duplicate ACKs can also be an indication of out-of-order packets.

If the packet with the missing sequence number arrives within 3 ms, Wireshark marks that packet as

Out-of-Order (tcp.analysis.out_of_order). If the packet with the missing sequence number arrives later than 3 ms. later, Wireshark will indicate that the packet is a either a Retransmission or a Fast Retransmission.

These Duplicate ACKs complain about a missing sequence number. If SACK is in use we should see

only the missing packets being retransmitted. The SACK Left Edge and SACK Right Edge fields in

the TCP Options area acknowledge other data packets received while the Acknowledgment Number

field still indicates the desired missing sequence number.

If SACK is not in use we may see many unnecessary retransmissions as the sender retransmits every

data packet starting at the missing sequence number.

Out-of-Order Packets

tcp.analysis.out_of_order  Out-of-order packets may not affect performance if there is very little time(1-3 ms) between their expected arrival and their actual arrival. If out-of-order packets arrive after quite a delay, or there are many out-of-order packets, there may be a noticeable degradation in performance. TCP cannot pass received data up to the application until all the bytes are in the correct order.

Determining if a packet is Out of order, Retransmission or Fast Retransmission

Fast Retransmission

tcp.analysis.fast_retransmission  Fast Retransmissions are triggered by receipt of three identical ACKs (the original ACK and two Duplicate ACKs).

Retransmission 

tcp.analysis.retransmission  Standard Retransmissions are not triggered by Duplicate ACKs. Standard Retransmissions are triggered by a Retransmission Time Out (RTO) at the sender. The RTO timer is used to ensure data delivery continues even if the TCP peer stops communicating (with ACKs). When the RTO timer expires without receiving an ACK for the data packet, the sender retransmits the unacknowledged data packet.

You do not want to spend time troubleshooting Retransmissions or Fast Retransmissions when these
packets are actually Out-of-Order packets that did not arrive within 3 ms of the higher Sequence
Number field value.

Remember, Duplicate ACKs lead to Fast Retransmissions. An expired RTO at the sender leads to
Retransmissions. Each of these is an indication of packet loss which typically occurs at interconnecting devices. Capturing at different points on the network can help you find the point of
packet loss.
Applications cannot pick up data from the buffer until all sequential bytes have been received. Outof-
Order problems typically aren't felt by network users unless there is a large gap in time between
the expected arrival time and actual arrival time.

ACKed Unseen Segment

tcp.analysis.ack_lost_segment  This Expert Infos warning indicates that Wireshark sees an ACK, but it did not see the data packet that is being acknowledged.

Zero Window

tcp.analysis.zero_window  Each side of a TCP conversation advertises its receive buffer space in the Window Size Value field (tcp.window_size_value). When a receiving application cannot pull data out of the receive buffer fast enough, this advertised Window Size value can drop to zero

The Window Size Value field indicates the actual Window Size being advertised. When Window

Scaling is in use, Wireshark multiplies the Scaling Factor by the advertised Window Size Value field

to provide the scaled Window Size (Calculated window size field). The TCP FIN or RST packets would not be colored by the Bad TCP.

Window Full

tcp.analysis.window_full  Window Full is an indication that the target will be out of receive buffer space when the data packet arrives. Use 'Bytes in Flight" to watch a stuck application.

Zero Window Probe and Zero Window Probe ACK

tcp.analysis.zero_window_probe, tcp.analysis.zero_window_probe_ack  Zero Window Probe packets may be sent by a host to a TCP peer that is advertising a Zero Window condition in the hope of eliciting a Window Update response. Keep in mind that a host may send a TCP Keep Alive (decrementing the sequence number by 1) instead of a Zero Window Probe packet.