<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<font face="Helvetica, Arial, sans-serif">Jim - I suspect your Comcast
support person was partly right. ICMP *echoing* is sidelined.
However, IP packets that contain ICMP messages destined farther down
the line are NOT dropped by routers and switches. That would be dumb,
though I'm sure some networks that don't want to monitor their own
congestion might be so dumb as to imagine that ICMP mice will somehow
overload a network. I don't think such people are members of NANOG).<br>
<br>
It turns out that Comcast's problem (extensively investigated by
technologists rather than their PR dept., only after the Harvard FCC
hearing) was that DOCSIS modems they had bought actually had
multiple-seconds worth of buffering on their upstream-facing
interfaces, and did not under any circumstances drop packets in a way
that would allow TCP to know enough to slow down the AI part of AIMD.<br>
<br>
Given the sidelining of *echoing* yes, pinging a router might not give
much info about that router. But pinging the next, unloaded router
down the route will tell you a lot.<br>
<br>
In any case, it's easy to open up a TCP connection and carry out an
end-to-end ping without ever using ICMP. Just wait a few seconds after
a sync, send a few bytes, and have a responder echo them. If you use
TCPNODELAY option, you will get a reliable result. I have a python
program on my server that handles such things. In this particular
measurement, the data from this "TCP ping" gave consistent RTT's with
the ICMP ping.<br>
<br>
It's fascinating to me that people REALLY WANT to call this
"measurement error". </font>As opposed to *operator*
misconfiguration (or router-designer-error).<br>
<br>
Perhaps someone might actually be able to guess what manufacturer sells
the equipment that routinely buffers 8 seconds of outgoing packets on a
link without a hint of backpressure that would allow TCP's congestion
control to kick in?<br>
<br>
I just want to see it fixed before Sandvine sells some more
TCP-RST-injectors and DPI spies to that vendor, and starts accusing
people with some very cool handsets of "attacking the network". Maybe
the handset vendor would be interested in having interactions take less
than 8-20 seconds between gesture and response from a server? <br>
<br>
One thing that is clear: the spate of news stories about "spectrum
shortage" has missed a fundamental technical problem that has NOTHING
to do with spectrum.<br>
<br>
<br>
</body>
</html>