[e2e] What's wrong with this picture?
David P. Reed
dpreed at reed.com
Mon Sep 7 06:30:49 PDT 2009
You are overthinking this. I can share with you the delays using a
personal hack "tcp ping" tool that sends a few bytes over a TCPNODELAY
socket. They are consistent with this measure.
Measurements are never perfect, but that doesn't mean they can't tell us
a lot. I used to diagnose the Multics operating system performance
problems by studying the panel register display. Rarely needed to write
special profiling code
On 09/07/2009 06:46 AM, Jeroen Massar wrote:
> Ihsan Ayyub Qazi wrote:
>> TCP != ICMP ;)
>> Sure but the large delay (and variation) is probably due to large
>> buffers getting filled up by TCP traffic; ping just measured the delay
>> rather than causing it.
> That is not what I meant. Just think of the case where there is a nice
> ISP involved, or for that matter several, who are doing "QoS" and
> prioritizes ICMP a lot lower than TCP... you do know that all bittorrent
> is evil and that everything over port 80 is 'good' don't you? :)
> Also think of that little fact that traceroute is unidirectional, you
> only see the return path from your vantage point, not the path that the
> packets are taking from those points, you know that the RTT is<x> but
> you don't know if that is a symmetric path or not, let alone where the
> delay is happening. This is why there was this feature called
> source-routing which allowed one to partially make that happen, but
> unfortunately that feature has a lot of abuse added to it.
> David: a cooler question would involve some 6to4 hosts, then one really
> does not know where the packets are truly going ;)
> As long as one does not own/control/operate the complete path it will be
> really quite hard to tell what happens to packets outside ones control.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest