i'm trying to get the RTT samples using tshark, most of the application i observe do not use piggybacking property of the TCP. if it is used is there any considerations/differences for RTT calculation with/without piggybacking? (user think times or any other noises will effect the RTT(?) Thanks. asked 23 Mar '11, 12:41  berkey edited 23 Mar '11, 12:42 |
One Answer:
The easiest way, IMHO, to get RTT data is just to watch the 3 way handshake at the beginning of a TCP conversation. There's no piggybacking taking place because the conversation is just getting started. This is a slightly better method of RTT calculation than using piggyback packets - though neither are totally reliable. Why, you ask? Usually there is no system delay associated with the 3 way handshake - the stack attempts to setup the TCP session as soon as possible. There is very little processing involved, and so this usually takes place very quickly. It's possible that a resource starved server could have delays in packet generation, but it's been my experience that this rarely affects the handshake. With piggybacking, however, it's possible that the ACK packet is delayed while new data is being prepared for transmission. There could be significant delays in data bearing packet generation from a server that is resource starved/under burden. answered 23 Mar '11, 12:52  GeonJay |
@GeonJay, thanks for the great post +1. But ACK packets should be delayed how long? who decides ? so my idea is to formulate this effect depending on the application using wireshark.
In a perfect world where there was plenty of available data to transfer and the server was under no burden (SSD harddrives, efficient protocol, nothing SWAP'ed out, etc) there would be no delay..if you grabbed some packets in the middle of a huge file transfer you would be able to watch ACKs and/or piggyback'd ACKs and feel pretty comfortable with the RTT that you derived. If the data is being slowly trickled to the IP stack then it's possible that Nagle's could cause some delay. RTT derivation will always be relative - bandwidth bottlenecks, queue delays, solar flares, etc can cause delays.
@GeonJay, i understand, 200ms-500ms delay is possible according to my searches for waiting before sending the pure "ACK". is piggybacking supported for all applications ? my observations show that it is not used that much?
You won't see piggybacking a lot because there aren't a lot of "full duplex" applications. Usually if I'm downloading something from you I won't also be sending data to you at the same time. A lot of the seemingly full duplex applications (video/voice chat, etc) are UDP, so they also won't use any kind of piggybacking.
200-500ms seems pretty extreme for ACK only packet generation - but it's possible if the server is under load. Good ol' ICMP ping can be a fairly reliable source for RTT as well.
@GeonJay, thanks for making me clear.