|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical [[email protected]: Re: Network for Sale]
arg forgot the nanog-post thing at first.. -- Philippe Strauss, safehost sa En offrant aux regards trop de drame humain, la technologie nous a desensibilis�s, tant sur notre propre souffrance que sur celle des autres. --- Begin Message ---On Tue, Feb 20, 2001 at 07:22:54AM -0800, Paul Vixie wrote: > > [email protected] (John Fraizer) writes: > > > I suspect that your new technology simply adds another variable to the > > best-path-selection process based on your ping/traceroute script RTT's to > > a specific network based on what you have divolged thusfar. > > Oh god, I hope not. RTT has never been an accurate predictor of end-to-end > performance. (Just ask anyone who bought into ping-based global server load > balancing.) ASPATH length is almost as bad (as a predictor) as RTT. well, it's the way icmp_echo is handeld in some vendor routers and sometime also the poor implementation of an IP stack on the echoing device which is a problem. another mean to measure RTT and packet loss rate is to analyze normal TCP traffic flowing between customers site and the internet. using a software tracking each TCP connection, you could get statistics like RTT and packet drop rate, on real world traffic. you could look for the worst packet drop stats, weight it relative to its statistical significance (higher the number of packet exchanged, better the accuracy), sort this statistics, and look for destination network who collect the worst packet drop rate (worst mean higher to me for packet drop). Then walk in you BGP table, look for another path than the selected one, try it, and compare the stats for this network, keeping this BGP tweaking in case the situation imprioved sensibly. This rise a big question: how a customer would perceive the fact that the provider analyse traffic for performance improvement reasons? the provider can ensure it's customer it wont use it to look into the payload, and actually be honest about it. Do you think customer will get mad about such an idea, or finally, since the (colloc) provider as physical access to shared equipment it would not change much the trust relationship needed btw the prvider and its customer. > Serve to learn, man. -- Philippe Strauss, safehost sa En offrant aux regards trop de drame humain, la technologie nous a desensibilis�s, tant sur notre propre souffrance que sur celle des autres.--- End Message ---
|