Home 
 Services 
 Analysis Resources 
 FAQs 
 About NPS 
 Events 
FAQs
What is TCP Windowsize?
How do I change the TCP Windowsize?
Can I capture physical layer errors with my software protocol analyzer ?
Why am I seeing so many Long Ack symptoms on my protocol analyzer ?
How can I find the NetBIOS name of a computer on the network ?
Which Duplex settings work, and which do not ?
What are Application Turns ?
Why am I seeing so many Fast Retransmissions on my protocol analyzer?
What are some ways of capturing packets in a switched environment?
What is TCP Windowsize?
The TCP Windowsize defines the size in bytes of the receive buffer used in a TCP conversation between two devices. The sending device in the conversation can transmit bytes to the receiving device until it has reached the number of bytes advertised by the receiver's TCP Windowsize. Once this number of bytes has been reached, the transmitter must stop transmitting until it receives an acknowledgement for some or all of the bytes sent to the receiver.
For optimal throughput, the TCP Windowsize should be based on the speed of the link between the two devices and the roundtrip time between the two devices. The windowsize can be calculated using the following formula:
TCP Windowsize = Bandwidth * Roundtrip Time
For example:
TCP Windowsize = Bandwidth of T-1 Circuit * Roundtrip Delay of 40 milliseconds
TCP Windowsize = 192,000 Bytes/Second * 0.040 Seconds
TCP Windowsize = 7680 Bytes
It is best to make the TCP Windowsize a multiple of 1460 bytes, as this is the size block of data that most systems will use on an Ethernet network. For the example above, we would round the TCP Windowsize value up to 8760.
To take spikes in roundtrip latency into account, it is best to double the calculated TCP Windowsize. This would make the preferred value for the above example 17520, which happens to be the default value for Microsoft Windows 2000 and Windows XP.
Since the TCP Windowsize is a product of bandwidth and latency, if either one of these increases, so should the TCP Windowsize.
How do I change the TCP Windowsize?
The TCP Windowsize for Microsoft products can be changed through the registry. Use the following links to review the Microsoft Knowledgebase articles on changing the windowsize values.
Can I capture physical layer errors with my software protocol analyzer ?
Most software based protocol analyzers use the Network Driver Interface Specification (NDIS) to communicate with the network interface card. While this allows the analyzer to capture all packets seen by the interface card, it will not pass physical layer errors, CRC errors and fragments, up the protocol stack to the analysis software.
Some analyzers, such as Network Associates Sniffer™ have drivers for specific network interface cards that bypass the NDIS drivers and pass the physical layer errors up to the analysis software. If you are using the Network Associates Sniffer™ the Xircom CBE2- 10/100TX card has such drivers available for it. These drivers are located in a \Program Files\NAI\SnifferNT\Drivers directory.
Most hardware based analyzers such as the Fluke Networks OptiView Integrated Network Analyzer, Workgroup Analyzer, and Link Analyzer have the ability to capture and decode physical layer errors.
Why am I seeing so many Long Ack symptoms on my protocol analyzer ?
Often times when capturing traffic on Microsoft systems your analyzer will report a high number of Long Ack symptoms. By default the Microsoft TCP stack will acknowledge every other TCP packet. If the sending device transmits an odd number of TCP packets, the receiving device will wait 200 milliseconds before sending an acknowledgement packet. Since the Long Acknowledgement symptom on most analyzers is set to 200 milliseconds, this delay will cause a symptom to be generated.
In most cases, this delayed acknowledgement does not cause a problem with the flow of packets. If the sending device is waiting for a response from the receiving device, it should receive the response immediately. If the sending device does not need a response from receiving device, the 200 millisecond delay does hurt anything.
One way to keep these symptoms from clogging up the expert symptom windows is to change the threshold for the symptom. This threshold can be increased to 250 milliseconds. This will reduce the false positives, but still monitor the network for actual problems.
How can I find the NetBIOS name of a computer on the network ?
From the a DOS prompt enter the following command:
nbtstat -A [IP Address] - Where IP Address is the IP Address of the computer to be queried
This will return the NetBIOS names that the computer has registered in addition to the MAC address of the NIC card that corresponds with the IP address entered in the command.
Which Duplex settings work, and which do not ?
A mismatch in duplex settings on an Ethernet link can cause a major reduction in throughput. The table below shows which settings work together and which do not.
 
Auto Detect
Half Duplex
Full Duplex
Auto Detect
Works most the time
Works, but not preferred
Will cause problems
Half Duplex
Works, but not preferred
Works well
Will cause problems
Full Duplex
Will cause problems
Will cause problems
Works well
When a link is forced to a specific duplex setting such as half or full, it stops sending the Fast Link Pulse (FLP). The FLP is responsible for notifying the other end of the connection the capabilities of the end sending the FLP. If a port set to auto-detect and it does not receive a FLP, it assumes the other end of the connection is set to half duplex.
What are Application Turns ?
Application Turns describes the number of requests and corresponding responses sent by an application during the completion of a task. A single application request may result in multiple response packets, but still represents only one turn.
The important thing to understand is that an application turn results in waiting the full roundtrip time between the client and server. On a LAN, this time is typically very small and has little impact on the application. On a WAN however, this roundtrip time can have a significant impact on the application. This is why many applications that work well on the LAN fail miserably on the WAN.
The key to writing WAN friendly applications is to keep the number of application turns to a minimum. This can be accomplished by reducing the number of database calls or HTTP Gets in an application.
Why am I seeing so many Fast Retransmissions on my protocol analyzer?
Fast Retransmission symptoms appear when the protocol analyzer sees the same TCP data and sequence numbers sent in a time period shorter then the Fast Retransmission value set in the expert portion of the analyzer. This value is typically 50 milliseconds.
In most cases though these retransmissions are not being sent by the TCP stack. In fact, they are not really being sent on the wire at all. The retransmissions are a result of the protocol analyzer seeing the same frame twice before it is sent down to the data link layer of the OSI stack on the computer. This can be caused by various drivers that are bound to the Network Interface Card. In most cases a VPN driver can cause this behavior.
So, how do you know of the packet you are seeing is really a Fast Retransmission, or if it is a problem with the stack on you computer? The first thing to check is the IP Header Identification. When a packet is really retransmitted, the IP portion of the stack will assign a unique Identification number to the outgoing packet. Even if the TCP information is exactly the same, the IP Header will be different. If the IP Header Identification number is the same in two frames, it is the result of either a layer 2 loop on the network such as a spanning tree problem, or a problem with the stack on the capturing computer.
How do we get a good capture? As a matter of practice, I don't use the same computer to capture the network traffic as I use to run the application being tested. I know that in Full Duplex environments it is much easier to capture on the same machine, but to get a good clean capture this may not always work. I will usually place a 10/100 hub between the device being tested and the network. This way I can plug my protocol analyzer into the hub and see all of the packets between the test computer and the rest of the network.
What are some ways of capturing packets in a switched environment?
Back in the day when 10 meg shared Ethernet was all the rage, it was pretty easy to capture packets. You could pretty much plug the protocol analyzer into any port of the hub and see all of the traffic. In most cases, you could let the analyzer run for a entire day without filling up the 16 meg capture buffer.
Today things are much different. Most networks are switched and running full duplex Ethernet. This means that if we plug our protocol analyzer into just any port on the switch, all we will see is Broadcast packets. This is great if you are doing a broadcast analysis of the segment, but typically we need to see more than just broadcasts.
Here are the three methods I usually use for capturing packets in a switched environment:
The Hub -
Good Points
Easy. You can install a 10/100 hub between the workstation and the network. Plug your analyzer in and you will see all of the traffic to and from the workstation. You have to make sure you are connecting at the same speed as the workstation when using a dual speed hub. If you are at 100 and the workstation is a 10, you will only see broadcasts. I like the NetGear DS108 hub for doing captures. It has worked well and it is really a hub. Some manufacturers call a device a hub when it is really a switch.
Bad Points
You must break the link between the device to be monitored and the network to install the hub. If the device you are monitoring is a mission critical device, this might be a problem.
Half Duplex. Hubs are half duplex devices and as such only support traffic flowing in one direction at a time. If you are trying to test something that is full duplex, you will have problems.
SPAN/MIRROR Port
Good Points
Does not require you to break the link between the workstation and the switch.
Allows you to monitor Full Duplex connections with a Half Duplex analyzer.
Can be configured remotely.
Bad Points
Must be able to login to switch in order to configure this option.
The switch must support Span/Mirror ports.
Most switches only support one Span/Mirror per device.
Some switches will only monitor traffic in one direction. You will only be able to see the packets in or out of the monitored port. Makes analysis VERY difficult.
If the bit rate of the traffic in and out of the monitored port exceeds the transmit rate of the port used to do the monitoring, packets can be lost.
VLAN tags a typically removed before the the packets are sent out the monitor port.
Frames containing physical level errors are not copied to the monitor port.
Inline Taps
Good Points
Preserves VLAN tags.
Can capture frames containing physical level errors.
Can capture Full Duplex traffic at full line rate.
Does not require access to switch configuration.
Bad Points
Must break link between switch and device to insert tap.
The analyzer used to capture the packets must be able to receive packets on two interfaces at the same time. These packet streams must be synchronized and put back into a single stream for analysis. Examples of these analyzers are Fluke Networks Link Analyzer and Finisar's THG.
Top