[e2e] What's wrong with this picture?

[Jon Crowcroft]

yes, its clear that "ping" is a higher freqency 
(just say "ping" out loud) than 
the gutteral trrracerroute
and abhorrent bittorrent is basso profundo,

thus imperfect band pass filters
will impact their mileage
differentially...

and of course
commercially minded ISPs 
may be carrying
deep pocket inspection
so more seriously:

of course, in a sane world,
QoS only takes away from
customers willing to pay less
when there are customers
willing to pay more 
(c.f. work conservation #101)
and not away from everyone 
in the working class
when there's nothing else 
going on in the upper echelons;

but it is
problematical for the user
to tell if this is what is going on
reproduceably.

In missive <1252327037.4357.39.camel at fedora>, Stjepan Gros typed:

 >>On Mon, 2009-09-07 at 12:46 +0200, 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? :)
 >>
 >>In the presence of QoS, it's hard to conclude something about one
 >>protocol (TCP) from the measurements performed with another protocol
 >>(ICMP) if at least some assumptions are made. But, in this case, it
 >>_could_ be that the conclusions are similar:
 >>
 >>1. For a start, I would always give higher priority to ICMP and
 >>traceroute, simply to be able to detect when something is wrong in the
 >>network, even when it is congested. But I do not have any operational
 >>experience, so I'm speculating. Anyway, in that case, ICMP traffic is a
 >>lower bound on delay TCP will get.
 >>
 >>2. If, on the other hand, ICMP has lower priority than TCP, then the
 >>delay can be from around 0 up to the given value, but since ICMP is
 >>going only after TCP has been sent than it represents upper bound on
 >>TCP's delay which means that, at least some connections, experience
 >>approximately equal delay to ICMP packets, bringing us again to the high
 >>delay in network.
 >>
 >>> 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.
 >>
 >>I don't get this one, i.e. that we see "return path"? Maybe I didn't
 >>understand what you meant, but as I understand it we could see different
 >>interfaces on the routers when the packet is going _to_ the destination,
 >>but in any case, we see routers that the packet is going through to the
 >>destination, not the path the response is sent back. But I agree that
 >>traceroute could be misleading...
 >>
 >>BTW let me try additional guess, again, under the assumption of (almost)
 >>no QoS. If I assume that ping times to the node lcs.mit.edu and to the
 >>node 172.26.248.2 are measured at the same level of congestion, then did
 >>this unnamed ISP decided to do aggressive buffering in the node
 >>172.26.248.2 (or something similar that has the same effect)? That would
 >>be one possible explanation what's happening. Namely, traffic that goes
 >>through node 172.26.248.2 is blocked on the outgoing line which incurs
 >>high RTT, but the traffic to the node itself goes directly to the CPU
 >>and response is sent immediately back yielding lower RTT?
 >>
 >>Stjepan
 >>
 >>P.S. With all the recent hype of ISPs doing traffic limiting and
 >>similar, I doubt that this has nothing to do with QoS, making my guesses
 >>a bit wrong, but it's interesting nevertheless... :)
 >>

 cheers

   jon