Is anyone out there familiar with a company called "routescience"? I caught
the below press release at and wanted to find out if anyone can relay any
real-world experiences with their system? It almost sounds like they are
using something like a Keynote Systems performance monitoring tool to inject
BGP path preference information.
TIA,
Irwin
I'm not really qualified to evaluate the technology, but the 4 minute flash demo on the site states that the system uses non-BGP approach to determine response time and load on selected links, as an alternative to just selecting least-hop AS statistics with BGP. Check out the 'technology' section of the Web site.
TR
Changing routing information depending on traffic is rather dangerous;
do they proivide adequate damping so the system does not oscillate? Is
such damping guaranteed to work under a wide range of load patterns?
NSFNET experiments with dynamic load balancing come to mind.
Now, if I were an ISP operator I would be very unhappy if someone injects
deliberately changing routes into my BGP mesh; while few such customers
may be surviuvable (if their systems do not get to "metric-flap"), having
many such customers is a sure way to overload core routers' CPUs.
Time to institute MED fixing on customer BGP sessions?
--vadim
Irwin,
thanks for noticing, and thinking about, our recent
press release. Some quick points to the questions you
have raised:
The RouteScience PathControl product which was announced
today
- supports active and/or passive measurements
- is designed to optimize the egress routing decisions of
multihomed enterprise customers. The performance routes
are intended for the enterprise "EdgeRouters", and are
not intended for propagation to upstream service provider
routes.
(We see a world of difference between the kinds of BGP
changes appropriate in a "leaf node" AS, versus those
AS's which provide transit.)
We're definitely interested in comments and suggestions. 
cheers -- Sean
Irwin Lazar wrote:
Vadim,
we recognize, and appreciate your concerns.
Two major points with regard to the PathControl product,
and it's impact on the BGP environments:
1) PathControl is currently targeted toward providing
optimized egress routes to multihomed enterprises.
Our technology is applicable to core routing, but
we certainly acknowledge the constraints in that
environment are radically different ...
2) We've integrated extensive anti-flapping capabilities
into the product, and in addition have user-configurable
settings for maximum rate of route change.
Given a high rate of changing performance measurements, the box
is capable of generating routing decisions at a high rate.
Our analysis (and default settings) show that significant
performance gains can be realized with a rate of change in
typical deployments less than ~100 prefix changes per hour.
(And maximum rates can be constrained lower than this,
if desired.)
cheers -- Sean
Vadim Antonov wrote:
Return-path: <owner-nanog@merit.edu>
Received: from psg.com ([147.28.0.62])
by rip.psg.com with esmtp (Exim 3.33 #1)
id 15YyHE-0001K5-00
for randy@rip.psg.com; Mon, 20 Aug 2001 16:16:12 -0700
Received: from trapdoor.merit.edu ([198.108.1.26])
by psg.com with esmtp (Exim 3.33 #1)
id 15YyH9-000BoL-00
for randy@psg.com; Mon, 20 Aug 2001 16:16:07 -0700
Received: by trapdoor.merit.edu (Postfix)
id 6E4589125A; Mon, 20 Aug 2001 19:13:39 -0400 (EDT)
Delivered-To: nanog-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
id 401239125B; Mon, 20 Aug 2001 19:13:39 -0400 (EDT)
Delivered-To: nanog@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
by trapdoor.merit.edu (Postfix) with ESMTP id ACD079125A
for <nanog@trapdoor.merit.edu>; Mon, 20 Aug 2001 19:13:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
id 7FF3A5DDC6; Mon, 20 Aug 2001 19:13:36 -0400 (EDT)
Delivered-To: nanog@merit.edu
Received: from taxi.speedtrak.com (ssfnat-204.routescience.com [64.254.174.204])
by segue.merit.edu (Postfix) with ESMTP id D54645DDA1
for <nanog@merit.edu>; Mon, 20 Aug 2001 19:13:35 -0400 (EDT)
Received: from routescience.com (dhcp-64-101.speedtrak.com [192.168.64.101])
by taxi.speedtrak.com (8.11.1/8.11.1) with ESMTP id f7KNDTT25695;
Mon, 20 Aug 2001 16:13:29 -0700
Message-ID: <3B819999.AA6D0907@routescience.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <Pine.LNX.4.10.10108201539210.27998-100000@arch.exigengroup.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-nanog@merit.edu
Precedence: bulk
Errors-To: owner-nanog-outgoing@merit.edu
X-Loop: nanog
Date: Mon, 20 Aug 2001 16:13:29 -0700
From: Sean Finn <seanf@routescience.com>
Organization: Newly Organized.
To: Vadim Antonov <avg@exigengroup.com>
Vadim,we recognize, and appreciate your concerns.
Two major points with regard to the PathControl product,
and it's impact on the BGP environments:1) PathControl is currently targeted toward providing
optimized egress routes to multihomed enterprises.
Our technology is applicable to core routing, but
we certainly acknowledge the constraints in that
environment are radically different ...2) We've integrated extensive anti-flapping capabilities
into the product, and in addition have user-configurable
settings for maximum rate of route change.Given a high rate of changing performance measurements, the box
is capable of generating routing decisions at a high rate.
Our analysis (and default settings) show that significant
performance gains can be realized with a rate of change in
typical deployments less than ~100 prefix changes per hour.
(And maximum rates can be constrained lower than this,
if desired.)
you're doing releasing just the perfect kind of sheep to graze the routing
commons of which i have been speaking, for example see
<http://psg.com/~randy/010809.ptomaine.pdf>,
folk, it's time to get those prefix length filters in before the real
/22-/24 pollution gets really crazy.
randy
Randy Bush wrote:
> Vadim,
>
> we recognize, and appreciate your concerns.
>
> Two major points with regard to the PathControl product,
> and it's impact on the BGP environments:
>
> 1) PathControl is currently targeted toward providing
> optimized egress routes to multihomed enterprises.
> Our technology is applicable to core routing, but
> we certainly acknowledge the constraints in that
> environment are radically different ...
>
> 2) We've integrated extensive anti-flapping capabilities
> into the product, and in addition have user-configurable
> settings for maximum rate of route change.
>
> Given a high rate of changing performance measurements, the box
> is capable of generating routing decisions at a high rate.
> Our analysis (and default settings) show that significant
> performance gains can be realized with a rate of change in
> typical deployments less than ~100 prefix changes per hour.
> (And maximum rates can be constrained lower than this,
> if desired.)you're doing releasing just the perfect kind of sheep to graze the routing
commons of which i have been speaking, for example see
<http://psg.com/~randy/010809.ptomaine.pdf>,folk, it's time to get those prefix length filters in before the real
/22-/24 pollution gets really crazy.
Randy,
please allow me to make clear ...
The PathControl product does *not* add routes to anyone's table;
it merely provides multihomed "leaf AS's" the ability to make
informed decisions about how to use the routes that their service
providers give to them.
So it can only optimize outbound traffic?
Hmm... Sometimes that can be useful, too.
--vadim
* Sean Finn sez:
The RouteScience PathControl product which was announced
today- supports active and/or passive measurements
What does that mean in 'non-buzzword' speak? In other words, if you'd
talk to someone who's actually seen a router at one or two occassions,
what would you tell him/her?
Is this YAPM (yeat another ping misuse), ROTEG (route optimization
through esoteric guessing) or something completely new such as (cough)
Gibsons 'nano-probes'?
So, if I am, say, yBay, a large used panties and fake celebrity
autograph auction house, how would I, given the diversity of my clients,
do any optimization?
jonas
> The PathControl product does *not* add routes to anyone's table;
> it merely provides multihomed "leaf AS's" the ability to make
> informed decisions about how to use the routes that their service
> providers give to them.So it can only optimize outbound traffic?
not nec'ily "traffic". but anything which optimizes the outbound route
chosen by tcp segments has the potential to increase the performance of
both the outbound tcp flow and the symmetrical inbound tcp flow.
Hmm... Sometimes that can be useful, too.
as i indicated back in 1997 at ftp://ftp.vix.com/pub/vixie/ifdefault/:
@Overhead @Title { Outbound Route Balancing } @Begin
@List
@LI { @S{TCP} is @S{ACK}-timed @Eq{arrowright} path symmetry is good. }
@LI { Symmetry in the intermediate system is really hard. }
@LI { First hop symmetry is most of what you want anyway. }
@LI { @S{BGP} path selection is hard to defeat. }
@EndList
@End @Overhead
Jonas,
Jonas Luster wrote:
* Sean Finn sez:
> The RouteScience PathControl product which was announced
> today
>
> - supports active and/or passive measurementsWhat does that mean in 'non-buzzword' speak? In other words, if you'd
talk to someone who's actually seen a router at one or two occassions,
what would you tell him/her?
A quick description is that PathControl optimizes the BGP decisions for
a multihomed organization. It passively measures performance over all
egress paths, in a manner described below. If active measurement to
selected destinations is required, it can be configured, but we view
that as strictly a supplemental source of data. An organization would
only actively probe endpoints who agree to such exchange; typically,
that might involve remote offices or B2B partners. (Ideally, one
PathControl would talk to another.)
Bottom line: PathControl does not automatically send unsolicited test
packets to anyone.
Is this YAPM (yeat another ping misuse), ROTEG (route optimization
through esoteric guessing) or something completely new such as (cough)
Gibsons 'nano-probes'?
IMHO, it's NOTA. (None Of The Above); but a more detailed description is
called for ...
So, if I am, say, yBay, a large used panties and fake celebrity
autograph auction house, how would I, given the diversity of my
clients, do any optimization?
The details of the measurement method were written up in Network World
yesterday; see
http://www.nwfusion.com/edge/news/2001/0820routescience.html
In short, the PathControl device serves a component of HTML content,
and by watching the detailed TCP behavior, it gains information on
the end to end latency and loss characteristics of every path out of
the organization.
The measurements are tailored to the NLRIs an organization actually
uses. We find that this greatly cuts down the number of updates we must
send to deliver effective results. Few "stub" organizations talk to
even 10% or 20% of the full table at a time.
PathControl then offers advice in the form of BGP updates to the edge
routers. The prefixes, the rate of change and the factors to optimize
can be constrained, between CLI commands on PathControl and the
conventional filtering offered within BGP on the edge routers. (FWIW,
PathControl marks any updates it sends with NO-EXPORT, as one more part
of ensuring that the changes are not propagated outside the AS.)
Obviously, I'd be more than happy to discuss this further; off-list may
be a better context for any really detailed conversation.
Mike Lloyd
CTO, RouteScience
The details of the measurement method were written up in Network World
yesterday; see
http://www.nwfusion.com/edge/news/2001/0820routescience.html
[ snip ]
PathControl then offers advice in the form of BGP updates to the edge
routers. The prefixes, the rate of change and the factors to optimize
can be constrained, between CLI commands on PathControl and the
conventional filtering offered within BGP on the edge routers. (FWIW,
[ snip ]
Let me go out on a limb:
Not sure that the NW article was "detailed", but I ass-u-me that one
measures the time from packet sent out until ACK, then uses packet
size and timing to determine the effective bandwidth.
Perturb the routing decision by inserting a longer subnet prefix.
Measure. Repeat until all paths have been timed. Repeat again to
lower standard deviation until the paths are statistically separated,
or bail if it's a losing battle. Now inject the "winning" route "for
good".
Setup procedure includes making sure that the border router doesn't
damp(en) paths learned from the route server. Measurement statistics
are keyed to the subnet learned from the border router, perhaps
aggregated with adjacent CIDR blocks if the results overlap.
Because it's futile to try tuning that occasional packet to Albania,
there's a low-water mark that a subnet (learned from the border) must
hit before any tuning occurs. Maintaining state is expensive, and
traffic follows the 80/20 rule... don't bother tuning unless many
packets go to that destination.
Observe-netflow-statistics-time-paths-and-reprogram-router done via
an automated black box. It's a route server whose adverts are
derived from empirical measurements. No?
<cynical>
I hope that the patent-pending part isn't any of the above, as the
above is hardly unique, innovative, or something that hasn't been done
before. If the above is "secret", and these boxen sell for ~$200k,
then I should turn this company into an R&D shop and implement some of
the ideas that we have on a much larger scale...
Shrouding something in secrecy tends to leave this crowd (NANOG-l) to
believe that there really is nothing to it... if it's that hard to do,
and has valuable substance, then why the hush?
</cynical>
I feel that I'm probably not the only one on NANOG-l who would like to
see some technical information ("technical" to routing geeks, not
"technical" to an end user or a Webbie) as opposed to "it's really
cool".
Back to my lurking corner,
Eddy
> The details of the measurement method were written up in Network World
yesterday; see
http://www.nwfusion.com/edge/news/2001/0820routescience.html[ snip ]
PathControl then offers advice in the form of BGP updates to the edge
routers. The prefixes, the rate of change and the factors to optimize
can be constrained, between CLI commands on PathControl and the
conventional filtering offered within BGP on the edge routers. (FWIW,[ snip ]
Let me go out on a limb:
Not sure that the NW article was "detailed", but I ass-u-me that one
measures the time from packet sent out until ACK, then uses packet
size and timing to determine the effective bandwidth.Perturb the routing decision by inserting a longer subnet prefix.
Measure. Repeat until all paths have been timed. Repeat again to
lower standard deviation until the paths are statistically separated,
or bail if it's a losing battle. Now inject the "winning" route "for
good".Setup procedure includes making sure that the border router doesn't
damp(en) paths learned from the route server. Measurement statistics
are keyed to the subnet learned from the border router, perhaps
aggregated with adjacent CIDR blocks if the results overlap.
If I am reading the "detailed" report right, the RS box actually is the border router:
"Entry-level pricing includes a modular, 14-slot chassis that occupies eight rack units and support for two ISP links. Optional modules can be added to support additional ISP links and enhanced reporting features."
In which case, perhaps it is trying to pop open HTTP packets and insert its stealth GIF on the fly, at line speed.
That's a lot of hardware for a function that might be better off embedded in the actual servers themselves ...
Peter
(Please wrap lines at ~72 chars)
If I am reading the "detailed" report right, the RS box actually
is the border router:"Entry-level pricing includes a modular, 14-slot chassis that
occupies eight rack units and support for two ISP links. Optional
modules can be added to support additional ISP links and enhanced
reporting features."
Ah. I skipped the part about "support for two ISP links".
In which case, perhaps it is trying to pop open HTTP packets and
insert its stealth GIF on the fly, at line speed.That's a lot of hardware for a function that might be better off
embedded in the actual servers themselves ...
In-server is what I initially thought of, too. However, then one
must coordinate between servers... what's wrong with a simple box
in promiscuous mode snagging eq 80 and eq 443 packets and dumping
the rest?
It just seems a shame to have to store and forward all the traffic
when one can analyze it from another viewpoint. Yes, managed
switches complicate sniffing, but many (most? all?) managed
switches have a "monitor port" that can wiretap traffic.
Eddy
(Please wrap lines at ~72 chars)
If I am reading the "detailed" report right, the RS box actually
is the border router:"Entry-level pricing includes a modular, 14-slot chassis that
occupies eight rack units and support for two ISP links. Optional
modules can be added to support additional ISP links and enhanced
reporting features."Ah. I skipped the part about "support for two ISP links".
In which case, perhaps it is trying to pop open HTTP packets and
insert its stealth GIF on the fly, at line speed.That's a lot of hardware for a function that might be better off
embedded in the actual servers themselves ...In-server is what I initially thought of, too. However, then one
must coordinate between servers... what's wrong with a simple box
in promiscuous mode snagging eq 80 and eq 443 packets and dumping
the rest?It just seems a shame to have to store and forward all the traffic
when one can analyze it from another viewpoint. Yes, managed
switches complicate sniffing, but many (most? all?) managed
switches have a "monitor port" that can wiretap traffic.
Unless you plan on "sniffing" your core router-to-router traffic (a very bad idea in my opinion) how do you deal with a web-hosting customer who is not sitting on a colo-LAN but rather across a WAN link of some variety?
Until we get the real low-down on the RouteScience design, no use speculating.
Peter
Eddy, Peter,
As I say, I'm very happy to discuss our approach, and our results. My
chief concerns are (a) not filling this list with product specs and (b)
competitive concerns.
I'm sure you've seen the situation many times before. NANOG folks want
details; vendors want to protect them. We have a healthy respect for
this audience, and I would like our technology to be understood here, in
terms of its impact and implications. I hope you can understand,
though, if I stop short of posting source code 
A major point to clean up first: PathControl is not a router. The
modular chassis we use comes from the need to scale; it takes quite a
bit of CPU to do this, and we need expandability to keep up with some of
our higher end trial customers! The device is out of line; it doesn't
even need a span port. As one of our users has commented, you can pull
out the "rip cord" (meaning the power cable) and your network's default
behaviour will immediately take over again.
"E.B. Dreger" wrote:
Let me go out on a limb:
Not sure that the NW article was "detailed", but I ass-u-me that one
measures the time from packet sent out until ACK, then uses packet
size and timing to determine the effective bandwidth.
In isolation, that fragment wouldn't get past a patent lawyer
Certainly, folks have addressed passive data collection from TCP
before. But the product we've announced involves the focused
integration and application of these pieces (along with some less well
known ones) in a standalone, manageable device which generates
controllable border optimization, targeted to user selectable goals.
That's still a bit of a mouthful, so let me get down to brass tacks.
The goes-inta's and goes-outa's from PathControl are all well understood
protocols: HTTP in, BGP out. (There's also the usual cast of characters
for a network device: SNMP, CLI, Web UI, etc. But now I'm getting back
to product spec recitation!) I'd like to keep some "special sauce"
defence around how we go from the input to the output, but certainly you
understand what we're basing it on.
Perturb the routing decision by inserting a longer subnet prefix.
Measure. Repeat until all paths have been timed. Repeat again to
lower standard deviation until the paths are statistically separated,
or bail if it's a losing battle. Now inject the "winning" route "for
good".
This is a common assumption, and we believe it describes some other
approaches, but it's certainly not true of PathControl. Sending "guinea
pig" route updates is a dangerous prospect. NLRIs with longer masks
present a number of problems, not least the risk of leaking them into
the outside world, which could be quite disastrous. (There are some
problems within the local AS too.)
A "guinea pig" route approach also means you cannot simply report on the
relative performance of network paths. PathControl can measure and
report on all available egress links without injecting any updates. All
you need is to arrange that the edge routers don't apply BGP to the
measurement stream. Folks here can probably imagine several ways to do
that ...
Setup procedure includes making sure that the border router doesn't
damp(en) paths learned from the route server. Measurement statistics
are keyed to the subnet learned from the border router, perhaps
aggregated with adjacent CIDR blocks if the results overlap.
Aggregation would be good, but it's tricky unless you wipe out the
original, more specific advertisements, which PathControl does not do.
Because it's futile to try tuning that occasional packet to Albania,
there's a low-water mark that a subnet (learned from the border) must
hit before any tuning occurs. Maintaining state is expensive, and
traffic follows the 80/20 rule... don't bother tuning unless many
packets go to that destination.
Again, an approach based on "guinea pig" routes will require this; you
must establish thresholds, and the approach cannot optimize below this
built-in "noise floor", which may have to be quite high to prevent
thrashing of distant prefixes.
But if you measure the alternate paths without sending any updates, now
you can consider any available improvement, without asking the operator
to write an essay in advance on acceptable network performance
characteristics. PathControl can measure improvements before it sends
any routes, and it then prioritizes to ensure the only updates sent are
those worth talking about, either because of performance, or other
constraints.
It's a route server whose adverts are
derived from empirical measurements. No?
That's a fair way to visualize what it does, yes.
How precisely we've done it, what kinds of controls we offer, how the
reporting looks, and ultimately how much it pays off are all things we
love to talk about, but I'm not sure this is the forum for brick by
brick architectural inspection. We have collected a large amount of
data on the relevant networking effects, and come up with analyses of
it; some of that might be appropriate at a NANOG meeting, perhaps.
<cynical>
I hope that the patent-pending part isn't any of the above, as the
above is hardly unique, innovative, or something that hasn't been done
before. If the above is "secret", and these boxen sell for ~$200k,
then I should turn this company into an R&D shop and implement some of
the ideas that we have on a much larger scale...Shrouding something in secrecy tends to leave this crowd (NANOG-l) to
believe that there really is nothing to it... if it's that hard to do,
and has valuable substance, then why the hush?</cynical>
Well, I'm not sure I'm invoking "secrecy" around the whole thing, but I
concede that we're not an open source outfit. I'd rather not offer the
list the manufacturing plans on how to build one, but I will confirm
your comments on what PathControl uses as a data source for decisions.
No doubt some folks reading this are implementing similar stuff; for
their benefit, I'll agree with Eddy that this is indeed quite hard to do
correctly! 
I feel that I'm probably not the only one on NANOG-l who would like to
see some technical information ("technical" to routing geeks, not
"technical" to an end user or a Webbie) as opposed to "it's really
cool".
Stick me in a kill file if I ever resort to "it's really cool"
Mike
I dunno about the rest of nanog, but I think a technical discussion of how
you implement performance-based route selection would beat the hell out of
the MAPS debate and Code Red discussion...I think, in fact, after touting
your product this much (which was in response, and not unsolicited, thus
relevant), you owe it to us to disclose as much as possible.
Plus, I suspect that either you have something really cool (in which case
I'd love to hear more of the details), or something that is going to be
picked apart by the heavyweights on this list (which would be highly
entertaining).
It's a no lose thread. Let's have it.
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Andy Dills 301-682-9972
Xecunet, LLC www.xecu.net
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dialup * Webhosting * E-Commerce * High-Speed Access
The goes-inta's and goes-outa's from PathControl are all well understood
protocols: HTTP in, BGP out.
Sounds quite dangerous.
Controlling (or zealously filtering) sources of routing information is a
necessity for any ISP which wants to offer dependable service and not live
in permanent fire-fighting mode.
> It's a route server whose adverts are
> derived from empirical measurements. No?That's a fair way to visualize what it does, yes.
How precisely we've done it, what kinds of controls we offer, how the
reporting looks, and ultimately how much it pays off are all things we
love to talk about, but I'm not sure this is the forum for brick by
brick architectural inspection. We have collected a large amount of
data on the relevant networking effects, and come up with analyses of
it; some of that might be appropriate at a NANOG meeting, perhaps.
My guess is that most network operations folks would be quite interested
in learning what kind of operational impact to expect from the deployment
of your boxes (and, frankly, what kind of defensive measures they have to
take to minimise the impact).
In this respect, giving the straight tecnical description is the best
thing you can do (if you believe that your technology is benigh). I hope
you understand that multihoming is always a special arrangement for ISPs,
dealt with on case-by-case basis, and many ISPs will simply refuse taking
any routes from customers unless they're convinced that customer has a
configuration which is highly unlikely to inject invalid or flapping
routes into provider's BGP.
No doubt some folks reading this are implementing similar stuff; for
their benefit, I'll agree with Eddy that this is indeed quite hard to do
correctly!
What is your definition of "correctly"? Providing benefit to this
particular customer? Providing benefit to the entire network? At what
cost to other customers and ISPs? Is stable operation guaranteed or
only highly probable? Etc.
--vadim
Vadim Antonov wrote:
Controlling (or zealously filtering) sources of routing information is a
necessity for any ISP which wants to offer dependable service and not live
in permanent fire-fighting mode.
My guess is that most network operations folks would be quite interested
in learning what kind of operational impact to expect from the deployment
of your boxes (and, frankly, what kind of defensive measures they have to
take to minimise the impact).
What is your definition of "correctly"? Providing benefit to this
particular customer? Providing benefit to the entire network? At what
cost to other customers and ISPs? Is stable operation guaranteed or
only highly probable? Etc.
All of your objections refer only to the attempt to control what path
inbound traffic takes. If you only control outbound traffic, these problems
don't arise. Arguably, for server farms, outbound packet loss and outbound
dealy times have a more serious affect on perceived performance than inbound
ones.
DS
Vadim, others,
Vadim Antonov wrote:
My guess is that most network operations folks would be quite interested
in learning what kind of operational impact to expect from the deployment
of your boxes (and, frankly, what kind of defensive measures they have to
take to minimise the impact).
As David Schwartz noted on the basis of earlier posts, and I would like
to confirm, the incarnation of PathControl we are discussing optimizes
outbound routing. I've received off-list mail on this question too, so
I'd like to be clear about it. The consequence is that ISP folks should
not be worried about new floods of strange-looking BGP data emerging
about their customers which they might be obliged to accept. The
customer outbound feeds will become no stranger than they are already
Applied in a stub AS, we do not create any prefixes which are not
already present. So as an ISP serving such a stub, you would be exposed
to what amounts to an (automated) change in internal policy for the
client AS - the same thing that would happen if they shifted local
prefs, or other controls, by hand. Either they now select you as the
winning advertisement where before they did not, or vice versa.
Once more, we do not cause the stub AS's own advertisement of themselves
to change. We specifically avoid touching locally originated prefixes.
If the ISP is currently accepting any of the routes PathControl is
designed to change, then the AS is not stub, it's transit. Hopefully
this clarifies an important issue.
(Referring back to Paul Vixie's point, we have found that careful
optimization of a single outbound step has very substantial payoffs in
terms of the end to end, bidirectional performance. The figures quoted
on our web page and in the press release refer to this: end to end
application speedup caused solely by outbound route selection!)
Mike