Re: [Bloat] Speed tests - attribution of latency to relevant network hops

[Jan Ceuleers <jan.ceuleers@gmail.com>]

On 30/07/15 15:04, Bill Ver Steeg (versteb) wrote:
> You do have to be careful using ttl tricks and/or ICMP packets for fine-grained timing measurements. On many middleboxes, there is a "fast path" that is done in a highly optimized manner (often in silicon) and a "slow path". In a non-zero number of cases, you will be in the fast path for normal packets and in the slow path for unusual packets. 

Yes, understood and agreed.

But I think it would already be very enlightening to lots of users (and
also assist the "make wifi faster" efforts) to understand how much of
the bloat sits in the part of the network that they can fix themselves,
how much of it they can hold their service provided accountable for and
how much of it they essentially have to put up with because it's
inherent to the way they're plumbed into the interweb.

So perhaps it's not possible to break the dslreports bloat graphs down
into the three segments that I described, because all we have available
is ICMP and the TTL field, but even a graphical representation of a
traceroute-while-idle and a traceroute-under-load would be a step forward.

> What you describe will work for the vast majority of cases, but there will be situations in which you will get misleading results. You would need to handle the timing differences when the slow path was MUCH slower than the fast path and it distorted the results. You would also have to handle some weird edge conditions..... The worst case that springs to mind would be a bloated buffer somewhere in a device's fast path (due to lots of "normal" packets), but the slow path on the same device is not congested and thus actually has less delay for this single packet.

My first thought was that I'd expect that the fast path queues in which
packets might spend a non-negligible amount of time would sit on the
egress side of the box rather than on the ingress side, and that it is
only the ingress queue that would affect both fast-path and slow-path
traffic. But I guess that this depends heavily on the architecture of
the box, so you're probably right.

Jan