|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Traceroute versus other performance measurement
Daniel Senie writes:
| All the theory sounds great. Now, you've got a customer using the utility to
| test a circuit between two boxes, and calls to complain that he's only
| seeing 1/2 of the expected bandwidth, because Pathchar tells him he's
| getting X, and we said we provisioned 2X. Perhaps it's just a customer
| education issue.
Or perhaps he is using pathchar correctly to measure the end-to-end
path characteristics between a specific source and a specific destination,
and is correctly complaining that your load-balancing solution does not
result in anything near the expected end-to-end available bandwidth.
| I think you're making assumptions about how load is shared on parallel
| links. Often this is done by hashing the IP address or mac address of the
| packets as a way to ensure there will be no packet reordering issues on the
| parallel links. You can send traffic until you clog one of the two pipes,
| but will never cause spill to the other link.
Yeah yeah I know nothing about leon the cleaner...
Consider the pathchar chase where the 5-tuple is hashed into buckets
which can be spread evenly among a set of lines; pathchar is thus
either a single flow or lots of flows, depending on how it does
things. If it's lots of flows, it represents the aggregate
bandwidth, which is meaningful if the end-to-end traffic is going
to be spread across lots of flows (e.g. web traffic, lots of small
transfers). If it's a single flow, it will measure a component,
and will be meaningful if the traffic is going to be big single
flows -- the degerate case of which is a single (encrypted) tunnel
for VPN-ish purposes.
If your customer expects to have traffic like the first case,
and complains because the component is measured, he or she needs
a simple explanation, and a simple demonstration (vary the 5-tuple,
or whatever information is used to generate the hash),.
However, if your customer expects to have traffic like the
second case, then perhaps she or he is right complain when
the component is measured.
You look good in any case if pathchar measures the aggregate
of the parallel paths; undeservedly so if real traffic is not
balanced properly.
Definitions:
n-tuple: a set of data of n discrete elements
5-tuple: dest addr, src addr, dest port, src port, tos/diffserv
1-tuple: dest addr [or dest prefix]
| You're making the assumption that you'll see change in the path FROM THE ONE
| STARTING POINT where you're running pathchar. This is simply not going to
| happen in many cases. Equal cost multipath, trunking and even unequal cost
| pathing will result in you seeing only a part of the picture.
Pathchar is not psychic; it assumes you are measuring the path characteristics
between the testing station and some arbitrary (but fixed) destination.
A big yellow warning label might be used to indicate that the path
characteristics to even the "previous" or "next" address "beside"
the target destination can result in dramatically different results
because of 5-tuple hash-based load-balancing is probably useful.
| Yet people run the tools, believe the results, even though the results
| aren't telling them the truth. This is backed up by observations in the real
| world, customer complaints and all.
Hey, people use all sorts of strange measurement tools which they
lack the skills to interpret. Many of them are in marketing departments...
Oh hey, there is a potential gun-control analogy here. :-)
Sean. (is that Godwin's Law yet?)
|