[34859] in North American Network Operators' Group
[philou@safe-host.net: Re: Network for Sale]
daemon@ATHENA.MIT.EDU (Philippe Strauss)
Wed Feb 21 09:57:46 2001
Date: Wed, 21 Feb 2001 15:39:58 +0100
From: Philippe Strauss <philou@safe-host.net>
To: nanog@merit.edu
Message-ID: <20010221153958.A2705@safe-host.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Errors-To: owner-nanog-outgoing@merit.edu
--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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.
--4Ckj6UjgE2iN1+kY
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Date: Wed, 21 Feb 2001 12:57:43 +0100
From: Philippe Strauss <philou@safe-host.net>
To: Paul Vixie <vixie@mfnx.net>
Cc: nanog@nanog.org
Subject: Re: Network for Sale
Message-ID: <20010221125743.A2444@safe-host.net>
References: <Pine.LNX.4.30.0102200024420.15008-100000@jay.internal.opnix.com> <Pine.LNX.4.21.0102200426570.18179-100000@Overkill.EnterZone.Net> <g3zofhbcq9.fsf@redpaul.mfnx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.15i
In-Reply-To: <g3zofhbcq9.fsf@redpaul.mfnx.net>; from vixie@mfnx.net on Tue, Feb 20, 2001 at 07:22:54AM -0800
X-NCC-RegID: ch.safehost
On Tue, Feb 20, 2001 at 07:22:54AM -0800, Paul Vixie wrote:
>
> nanog@Overkill.EnterZone.Net (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.
--4Ckj6UjgE2iN1+kY--
