[e2e] What's wrong with this picture?

[David P. Reed]

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.
>
> Greets,
>   Jeroen
>
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090907/84e744a8/attachment-0001.html