"To It" vs. "Through It"Far from a perfect analogy but this might help...
Imagine the water pump thingy in your house.
It's job is to move water THROUGH itself to where ever it may needed in your house. The sink. The shower.
Attached to all house water pumps is usually a diagnostic device. The water meter. In order to get the meter reading do we send a query THROUGH the pump to the sink or do we query the device housing/device chassis itself?
We (even if just with our eyes) look at the meter itself, not what is flowing through the meter.
The water pump does not care what the water meter does. It doesn't care if it even exists. FLOWING water THROUGH the pump is all it cares about.
In networking, there are usually two concepts that are referred to when talking about this stuff.
The
DATA PLANE. Real traffic.
THROUGH the device. The WATER itself. Often has lots of CPUs/ASICs dedicated to this one task.
The
CONTROL PLANE. The water METER.
TO the device. Often has just one CPU 'sorta dedicated' to this task.
When you happen to pass traffic through a router, by innocently browsing to some website or playing a game, your traffic falls under the DATA PLANE concept.
When you ping a router directly or perform a traceroute (which elicits a response from the router directly) your traffic falls under the CONTROL PLANE.
The control plane will often exhibit symptoms of higher latency even if the data plane is working perfectly. It's like if you've ever worked in a company where the sales team always get the red carpet treatment but the support team get the scraps. The data plane is the money. It's the real traffic. The control plane is subservient and de-prioritised.
On top of this, there are ways to further de-prioritise control plane responses. Control Plane Policing, for example:
https://www.cisco.com/c/en/us/about/security-center/copp-best-practices.htmlIn short, there are a whole bunch of reasons to take everything you see in a traceroute with a pinch of salt.
I stumbled across this PDF by Richard Steenbergen a few years ago and found it very useful:
https://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdfSo how do we get around all of this? How do we accurately measure end to end latency?
Cisco has another handy tool for this called IP SLA:
https://learningnetwork.cisco.com/blogs/vip-perspectives/2017/06/13/ip-sla-fundamentalsPart of this toolset is the ability to send SIP-like traffic through the network and actually generate a MOS score based on the jitter/loss it observes. Brilliant for the enterprise but what about the home enthusiast, I hear you cry?
I don't have an answer for this but I'd be very interested to hear what others have found that works for them?
Here's a question for you to see if any of this stuff makes sense.
Ping typically uses ICMP (as does traceroute). ICMP is considered a diagnostic protocol. It's a control plane protocol.
If I ping the bbc.co.uk server, do the routers/hops I pass through
to get there use their data plane or their control plane to route/forward my ping traffic?