Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How do I tell how much data is being transferred 1

Status
Not open for further replies.

hack12

IS-IT--Management
Dec 26, 2003
24
0
0
US
I am taking a sniffer capture and I am not sure how to tell how much data is being transferred. I am looking at the Length Field in the Decode Section and I see 1514. However the Total Length field in the ip header gives me 1500 bytes. In the TCP Header it tells me its 1460 Bytes of Data. Is that the actual data minus the ip and tcp header. If that is the case than what is the 1514. I can understand the 1500 would be 1460 (payload) + 20 (ip header) + 20 (tcp header) = 1500 but what is 1514. Is my thinking correct and can someone explain how to calculate it more accurately and what about with other protocols like netbios etc. Also is there a way to make sure that the mtu is always the maximum so as to optimize the connection. I have seen instances where the data is transferred in small sizes and hence it takes a long time. What does that depend on?
 
Just to add to the question above I forgot to ask how does the window size come into play and how is it optimized. Thanks
 
I think if you are using Ehernet or FastEthernet, perhaps you must add 12 Bytes of destination and source MAC address and 2 Bytes from the Ethertype. This bytes added to 1500 are the total size of the frame,1514.
 
1st question:
The maximum length of an Ethernet frame is 1518 bytes.
The math goes like this:
Layer2-Header: Ethernet - 18 byte
- Destination Address - 6 byte
- Source Address - 6 byte
- Length/Type - 2 byte
- Checksum (CRC) - 4 byte
The checksum is stripped off at the NIC level and thus not calculated in the Sniffer. This explaines a max frame size of 1514 shown in the analyzer.

Layer 3: IP - 20 byte (with no options)
At Layer 3 the max size incl headers is 1500 (MTU)

Layer 4: TCP - 20 byte (with no options)
Leaves 1460 byte of TCP data (whatever data this is)
(this is calles the max segment size, you find it in any SYN segment in a TCP session)

2nd question:
Window size relates to TCP sessions.
It shows, how much TCP-data a station can receive, before it has to acknowledge the reception of the data. Value is per TCP session and is inpependently configured per station.

Window size can have great impact on your throughput when sending a lot of data. Typical values are between 4k - 8k sometimes up to 16k.
My rule of thumb:
- Make the windows size on a client side larger, so that it can accommodate large amounts of data from fast servers.
- Make the window size on the server side a bit smaller, so that many sessions can be equally serviced.
- But the golden rule is: measure your throughput with the Sniffer on different window sizes.

Regards
Matthias
 
Hi Matthias,

How is life?
Send me a mail at info(AT)wullems.net
regards,
Robert



Robert Wullems
Network Specialist
SCP/SCE/SCM/CNX/MCP/MCSA/Network+
***************************************
If you can Sniff it, you can solve it!
***************************************
 
Hi Matthias,


Thank you for your reply. Just had a couple of other questions.

When you say TCP Data (1460) do you mean the actual data in the upper layers. Is that what is referred to as the payload. Also, can you give a small example of how would you measure throughput by using the sniffer. Thanks
 
hack12,
sorry for the delay.
You are right. 1460 Byte of TCP data is the actual data of the upper layers which is also referred to as the payload or the user data.
This statement is 100% correct for all TCP-based apps that run directly on top of TCP such as FTP, Telnet, etc.
In the Windows-world, there may be more protocol layers on top of TCP before you get to the actual user data.

Throughput can be measured as follows.
1) Throughput on the network (including headers and ACKs)
- Capture e.g. a file transfer
- Filter on the TCP-connection
- Look for the start of the TCP session (SYN, SYN-ACK, ACK)
- Set the mark on the first SYN frame for this session
(right-click in decode - Mark Current Frame)
- Enable Cummulative Bytes and relative time in Summary Decode (Display-Display Setup)
- Go to the end of the conversation
- Take the values of Cum. Bytes and relative time
- Throughput = Cum. Bytes / Rel Time

2) Throughput for the user (just user data, no headers or ACKs)
- Same procedure, just take the actual file size of the user file that got transmitted. Either you transfer a well-known file where you know the size.
You may also find the file size in the Sniffer. Examples: HTTP-traffic: Reply to a GET commend; FTP: Reply to a list-command; SMB: Reply to GET file attributes.

Hope this helps
Cheers
Matthias
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top