Using TCP Error Control for Troubleshooting

We mentioned in the last post about using some of the error control features of TCP to help solve problems with a slow network.   However although it’s true that these features do provide a very useful resource for troubleshooting, for those with less experience it can get a little confusing.  So lets try and put some of these features into some sort of context to start your troubleshooting journey.

Retransmission Packets

First consider why  retransmissions occur?  They happen when a client detects that the data it is sending is not being received properly.   Remember to consider where you are capturing your data from when considering these.  If you were capturing traffic at the problem end, say the server which wasn’t receiving the data, then you may not actually see these retransmission packets until you looked at the client side traffic.  This is important why when try to analyse an entire network that you start by finding a mirrored port on a central switch or hub initially, which will allow you access to the majority of traffic.   Sometimes you will first suspect the existence of these packets and you may need to go and look for them perhaps at the client end.

Duplicate ACK Packets

In some senses these are clues that the opposite side of the connection is at fault.  These duplicate ACKS are normally detected from the server side of  a connection because it has detected that a packet it was expecting from a client has been lost in transit.  You should be able to see them from both side of the connection if your network capture covers all the data.   These packets are created in one specific circumstance – when packets of data are being received in the wrong sequence.  Network with high latency and intermittent problems will often cause these packets to appear.   Consider the issue, data is being sent and received but sometimes individual packets are being lost or delayed creating these out of sequence acknowledgements.

Sliding Window Related

Packets that contain changes to the buffer size and keep alive packets related to the TCP sliding Windows mechanism are usually related with the servers inability to receive and process data in a timely manner.  Normally you wouldn’t see these packets on a fast, functioning network.   Very often they are not actually related to the network at all though but some issue with the servers ability to receive and process data quickly enough,  Often you will see these in hardware failures or perhaps someone overloading the server.  An example is when people use their RAS server to access region locked content which is typically video or multimedia.

A server can be brought to it’s knees very quickly if it is expected to process data it is not designed for – read this article on people using a VPN to bypass the Netflix blocks.    A server will start sending these packets in order to reduce the amount of data it is being sent, so when you see these packets first look at the server for investigation.  A look at the hardware error logs or the current connections will usually reveal some insight to the reason behind these packets being spotted directly on the wire.

Further Reading

About Residential VPN Services – http://www.theninjaproxy.org/technology/is-a-residential-vpn-service-essential-now/

One thought on “Using TCP Error Control for Troubleshooting

Leave a Reply

Your email address will not be published. Required fields are marked *