Subject: RE: delay calculation

From: Grotefeld Glenn-cecl03 <[email-masked]>
Date: Wed, 2 Aug 2000 12:53:13 -0500

I agree with Mr. Marcus.  Essentially, all three packets get a received
timestamp of t, no adjustments.

Glenn Grotefeld

Motorola, Inc.
[email-masked]
US  847 576-5992
      847 538-7455  FAX

~-----Original Message-----
~From: Scott Marcus [mailto:[email-masked]]
~Sent: Tuesday, August 01, 2000 12:19 PM
~To: C. Zhang
~Cc: [email-masked]; [email-masked]
~Subject: Re: delay calculation
~
~
~At 22:47 07/31/2000 -0600, C. Zhang wrote:
~>Hi all experts,
~>   If my client sends several tcp packets (say P1,P2,P3)
~>   very closely, TCP stack combines them into one message, 
~>   then send it to my server. Now at server I want to calculate 
~>   the delay of each packet. Since I only have one timestamp t, 
~>   which is the arrival time of the "chuck" message, how can I 
~>   calculate the different arrival time for the several packets? 
~>   
~>   If the packet sizes are L1, L2 and L3, is it correct to say that:
~>      	the arrival time of P1 is (t - (L2 + L3)/B ),
~>      	the arrival time of P2 is (t - L3/B ), 
~>      	the arrival time of P3 is t, 
~>   where B is the bandwidth of the link?
~
~
~
~As was previously noted, it depends on what you are trying to 
~achieve with
~your measurements.  But subtracting an estimate of the 
~theoretical minimum
~clocking delay for P2 and P3 (as you appear to be doing) 
~probably makes no
~sense, since your TCP implementation will not see the  the 
~contents of P1
~and P2  nor release them to the application until the whole 
~P1/P2/P3 packet
~has been received.  For practical purposes, the whole packet arrives at
~once.
~

---

From: "Perser, Jerry" <[email-masked]>
Date: Sat, 5 Aug 2000 01:06:00 -0700

You also make the assumption that the packets are received in order.  Since
one of the TCP layer's function is to reassemble IP packets into a datagram,
it will hide the IP layer properties from you.  I also agree with Marcus.

One thing I have done to keep the measurement meaniful is to keep everything
at the same layer.  If I am doing an L3 measurement, the setup parameters,
the transmit and receive timestamps, and the results are done at L3.

You might want to move your measurement to L4.  Send a L4 datagram with a
single timestamp.  Your server will put a single timestamp on the receive.
This will give you a meaningful L4 measurement.  Remember the L3 measurement
hides the L1 and L2 properties.  This L4 measurement will hide the L1, L2
ans L3 properties.

-----Original Message-----
From: Scott Marcus [mailto:[email-masked]]
Sent: Tuesday, August 01, 2000 10:19 AM
To: C. Zhang
Cc: [email-masked]; [email-masked]
Subject: Re: delay calculation

At 22:47 07/31/2000 -0600, C. Zhang wrote:
>Hi all experts,
>   If my client sends several tcp packets (say P1,P2,P3)
>   very closely, TCP stack combines them into one message, 
>   then send it to my server. Now at server I want to calculate 
>   the delay of each packet. Since I only have one timestamp t, 
>   which is the arrival time of the "chuck" message, how can I 
>   calculate the different arrival time for the several packets? 
>   
>   If the packet sizes are L1, L2 and L3, is it correct to say that:
>      	the arrival time of P1 is (t - (L2 + L3)/B ),
>      	the arrival time of P2 is (t - L3/B ), 
>      	the arrival time of P3 is t, 
>   where B is the bandwidth of the link?

As was previously noted, it depends on what you are trying to achieve with
your measurements.  But subtracting an estimate of the theoretical minimum
clocking delay for P2 and P3 (as you appear to be doing) probably makes no
sense, since your TCP implementation will not see the  the contents of P1
and P2  nor release them to the application until the whole P1/P2/P3 packet
has been received.  For practical purposes, the whole packet arrives at
once.

---

From: Grotefeld Glenn-cecl03 <[email-masked]>
Date: Fri, 11 Aug 2000 11:45:38 -0500

For the purpose of Network Performance Measurement for Periodic Streams
(npmps), we expect most test usage to be RTP/UDP rather than TCP.  This I-D
is very keenly interested in "in order" ("out of sequence") packets.

Glenn Grotefeld 

Motorola, Inc. 
[email-masked] 
US  847 576-5992 
      847 538-7455  FAX 

-----Original Message----- 
From: Scott Marcus [ mailto:[email-masked] <mailto:[email-masked]>
] 
Sent: Tuesday, August 01, 2000 10:19 AM 
To: C. Zhang 
Cc: [email-masked]; [email-masked] 
Subject: Re: delay calculation