On 4/23/2019 12:32 PM, Sake Blok | SYN-bit wrote:
>
> Please note that RTT calculations are done from the view of the capture point. So if you capture near system A, the roundtrip times for traffic being sent from A to B will be showing the 'real' roundtrip times, as the data packets are seen at the capture point just slightly after they have left system A. Then the ACK comes in after the packet has traversed the network over to system B and B sent the ACK back. But when system B sends data, it has already travelled the network all the way to system A, then A sends the ACK and it is seen by the capturing machine before it travels all the way back to system B.
>
> So, unless you are able to capture on the remote side, you will only be able to deduct the TCP RTT times by looking at the traffic that is sent from our side to the remote side.
>
In my case I have an 'A', (the client), a 'B', which is the
masquerading server, and a 'C' which is the remote service. I've been
doing my measurements on the server in between A and C, so I thought I'd
be able to pickup when packets were in transit on 'B'. It's just that
I am getting such wild values for A->C, but the reverse look to be
much lower jitter with most packets at 1ms or less and a comparatively
few packets up around 10ms. Vs. A->C which is showing packets all over
the place.
That's why I was thinking -- the only side even close to 1ms, could be
'A'->'B' (or rather 'B'->'A' for the reverse). That's why I'm wondering
while I measure C->A, I get the full rtt, but when I ask for the reverse
am wondering if I am really measuring B->A. My measuring system is
the server in the middle if that make sense.
If the measuring machine in your example is between A+B would I only see
the RTT time because of 'A's ACK or would I see it as the packet passes
through the "router" (masquerade box)?
So one of my graphs (the most chaotic looking) is measuring rtt from
'A' to 'B'
