cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Metrics Definitions

Hello,

I am creating a report using sever Two-Way Loss and RTT metrics, and I have some questions about their definitions.

1)

Network performance relevant bytes (id: relTraffic)

The total volume of TCP traffic. Includes both directions of data transfer, to and from client, or downstream and upstream, but does NOT include bytes transferred internally within the site.

Is "site" referring to "location", or something else?

2)

End-to-end ACK RTT (id: csAckRtt)

The time it takes for an ACK packet to travel from a client to the monitored server and back again.

End-to-end RTT (id: csRtt)

The time it takes for a SYN packet to travel from the client to a monitored server and back again.

Why isn't this named End-to-end SYN RTT?

3)

Client RTT (id: cRtt)

Client RTT is the time it takes for a SYN packet (sent by a server) to travel from the AMD to the client and back again, as shown in the following picture. A client RTT measurement begins when the SYN ACK packet from the server to the client passes by the AMD (T5). The packet reaches the client machine (T6) and is processed, while an acknowledgment is sent back to the server (T7). Client processing time impact (T7-T6) is again very low. Client RTT measurement ends when the ACK packet reaches the AMD (T8). Therefore, the Client Round Trip Time is calculated as T8-T5. Depending on the actual setup, Client RTT measurements may vary dramatically. In corporate environments, it may be a few milliseconds for LAN-connected clients or a couple dozens milliseconds for WAN-connected clients. In this case, where the client is coming from the Internet, the end-to-end Client RTT measurement is a compound of transit time through the Internet backbone as well as through the "last mile" access network. The impact of the last mile can be easily calculated, based on the connection speed and the packet size (56B in case of TCP SYN packet). For a 28 kbps dial-up connection, this amounts to 16 milliseconds one way, or 32 milliseconds for a complete round-trip measurement. For a 1.6 Mbps DSL line, this makes 56 microseconds towards complete client RTT measurement.

Server RTT (id: sRtt)

The time it takes for a SYN packet (sent by a user) to travel from the AMD to a monitored server and back again.

How does an RTT from /to the AMD assist in troubleshooting? Why the longer explanation for Client RTT vs. Server RTT? Again, shouldn't these be named Server SYN RTT and Client SYN RTT?

4)

Server ACK RTT (id: SA)

RTT measurement performed during ACK packet transmission, from server side of the operation. Also provided are minimum, maximum and standard deviation values.

Server ACK RTT measurements (id: SM)

These metrics keep track of how many RTT of Server ACK measurements were made. ACK measurement is performed during ACK packet transmission either from server or client side of the transaction.

What would be the cause of the Server ACK... metrics be zero or null?

Thanks and God bless,

Genesius

1 REPLY 1

matthew_eisengr
Inactive

1) Is "site" referring to "location", or something else? Site, as in the range of IPs you've associated with a location.

2) Why isn't this named End-to-end SYN RTT? Unsure on the reasoning for the name, it is just important to remember that any RTT measure is ONLY done when a TCP 3-way handshake happens. Any ACK RTT measure happens EVERY time an ACK is seen. So if you are looking at a service like Citrix that leaves TCP sessions pinned open for a long period of time, you won't have a very good idea of what's going on and it is better to use ACK RTT metrics.

3) How does an RTT from /to the AMD assist in troubleshooting? This can come in handy as it can point you toward where in the network the congestion is happening. So if your AMD is placed on the edge of your DC, you could quickly determine where the RTT slowness is happening... either outside the data centre or inside the data centre. In large environments, where the demarcation of responsibility is split between providers, i.e. WAN provider and DC provider, this can be very valuable in knowing who to call.

4) What would be the cause of the Server ACK... metrics be zero or null? Not quite sure on this one,

Hope that helps!