[e2e] What's wrong with this picture?

[Stjepan Gros]

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... :)