|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: number of hops != performance
>Does anyone have a nice reference I can point to to once and for all state >that just because a customer has 6-8 L3 hops within our network (all at >gigabit speeds or higher) that doesnt automatically mean they are getting >bad performance or higher latency. When I was at Ebone I would sometimes visit large accounts just to help the salespeople with this question. I would bring along a copy of our measurement data and show these customers exactly what our network latency was measured in milliseconds not in hops. Everyone understood milliseconds and I knew that our network had lower latency than the competition. Of course, the fact that we did measure latency with a matrix of over 20 cities was a strong selling point as was the fact that we made this data available to customers. The salespeople were overjoyed because this was far stronger than the material that our marketing department made available. >Hiding the L3 hops in a MPLS core (or other L2 switching) doesnt mean >customers are getting better performance since equipment today forwards >just as quickly on L3 as on L2. And this is exactly what I would explain. Customers are intelligent enough to understand that hops equal devices and that hiding the hops/devices from IP traceroutes does not make them go away. Then I told them that we engineered our network for speed (wirespeed switching, zero buffering, zero packet loss) so that we weren't ashamed of the hops. But perhaps the other guys had something to hide? When you have something great to sell, you have to cut through the bullshit and demonstrate the greatness to the customer. Assuming that they want low latency, you have to show them beyond a shadow of a doubt that your latency is low. And if your latency isn't low, then you need to either fix the problem or find customers who care about other things like PoP locations or SLA reporting or something other than network quality. --Michael Dillon
|