perfsonar development work

["Jeff W. Boote" <>]

There are two other ways I can think of:

1) If the two paths are not of equal length - then the TTL of the owamp packets 
will have differences. I would not expect that to be the case for load-balancing.

2) As Wenji suggests - I would expect the route flap to have a different time 
periodicity effects than the load balancing. OWD could be used to look for this, 
but you would need to be sending continuous streams of packets. We currently do 
10 packets/second in our measurements - I'm not sure that is frequent enough to 
look for this - we would need to see how quickly BGP updates happen on specific 
hardware. If it is frequent enough, I would expect more delay differences at a 
packet inter-gap level with the load balancing, and more differences by 
'groupings' with route flaps. But, this is just what I would expect... We would 
need to test this.

A lot also depends on the load-balancing hardware. Some hardware is smart enough 
to keep address tuples (src,dest,port) going the same route. In this case, owamp 
for example would only ever see one route from the load-balancer. (For the same 
test session since each session happens on a unique port.)

jeff

Wenji Wu wrote:
> Hi, Joe,
>
> Just based on the one-way delay, it might be hard to differentiate the load
> balancing and route flapping if those paths have similar one-way delays. And
> the queuing delay might easily hide the differences. We might need to
> combine with other measurement.
>
> Route flap might not happen so frequent because most routers would limit the
> frequency to update the routing tables or limit the rate to broadcast the
> route updates. For example, BGP router has the MRAI timer to limit the route
> updates. 
>
> However, load balancing could happen at the packet level.
>
> It sees to me that the best way to differentiate the route flap and load
> balancing might be traceroute.
>
> With traceroute, we could generate the sequence of router along the path
> from the src to dest. For Route flaps, the path might not change so
> frequently. Most traceroute will generate the paths within the intervals of
> route flaps.
>
> For load balancing, the paths might change at the packet levels. And
> traceroute will generate some weird results. For example, if we have the
> topology like:
>     c-d-e
>    /       \            
> a-b       I
>    \     / 
>     f-g-h
>
> node b will do the load balancing. We run traceroute from a to I. Then
> traceroute might generate no-existent links. Let's say, the third ICMP goes
> to C, and the fourth ICMP goes to F. then non-existent link C-F might be
> generated!
>
> So if it is the load balancing case, you run traceroute at different times,
> various results will be generated. It depends on the crossing traffic at the
> load-balancing nodes.
>
>
> wenji
>
> -----Original Message-----
> From: Joe Metzger [mailto:] 
> Sent: Friday, July 20, 2007 4:23 PM
> To: 
>
> Cc: 
>
> Subject: Question about interpreting One Way Delay data.
>
> Hi,
> An interesting question came up in the course of debugging a  
> performance problem today.
> It is not real important from an operational perspective, but it is  
> intriguing from
> an academic point of view.
>
> Is there a way to analyze one way latency measurements between  
> endpoints over long
> slow congested paths and differentiate between route-flapping and  
> load balancing?
>
> If so, do you need access to raw data, or can you do it from the type of
> summarization that the DFN and I2 tools are typically doing today?
>
> Thoughts?
>
> --Joe