[WinPcap-users] Calculating RTT & delay.

[KanjiSoft Systems]

Title: Message

Hi,   I'm planning to use a UDP probe and an acknowldedgement to calculate round trip time (RTT) over an internet connection.  The calculation is modeled on the RTT calculation used in RTP / RTCP.   It would work like this: a probe sent from the originating host will contain a sequence number. That sequence number will be returned in an acknowledgement. At the originating host, the difference between the (winpcap) sent time of the probe and receipt time of the acknowledgment can be used to determine RTT.   However, I would also like to subtract from the RTT this number:    The time differential between the point at which the probe reached the destination, and the point at which the acknowledgement exited the destination.   This last item will allow the true network latency time to be calculated, by eliminating the time the it took for the destination host to process the probe and generate the acknowledgement.   Thus, the full calcution:   RTT                            =   Time ack returned - time probe sent. Destination delay         =   time probe received - time ack sent   RTT Network Latency   =   RTT - destination delay   One way latency         =   RTT Network Latency / 2   There are a couple of problems with this. First is this a valid measure? Should the latency calculation include the "destination delay" - i.e., the time it takes the host to send the acknowlegement?   As mentioned, I'm trying to get a close approximation of the way RTCP calculates it. RTCP does in fact calculate the "destination delay" and includes it in the recommended calculation.   But the difference is, RTCP is an application layer protocol. That means the time received and time sent will include the time it takes the packet to traverse the protocol stack. On the other hand, the latency based on winpcap time will not include protocol stack traversal time, because that time used in the calc is based on the point at which it enters/exits the driver/nic card.   The second problem is an implementation issue.  The time at which the acknowledgement leaves the destination host isn't known until that point, so obviously the destination delay can't be communicated to the originating host until the subsequent. The RTT calculation will always be delated by one probe.  But there's nothing to be done about that, as far as I can see.   Any thoughts, comments, etc. much appreciated.   Regards, Mark