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

On Tue, 21 Aug 2001, Sean Finn wrote:

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 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 --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.

(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 --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.

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

On Wed, 22 Aug 2001, Mike Lloyd wrote:

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, 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

Can/will the box adjust inbound route selection via the use of prepending and/or provider communities? -C

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

-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

Christoper,

no, the PathControl device does *not* adjust outgoing advertisements in any way; all prefixes that we repeat carry the NO_EXPORT attribute.

And if the ISP using your box has downstream BGP customers in different ASes? The NO_EXPORT tag really serves no purpose here because any ISP that would be avertising your bozxes routes to its upstreams already has a much bigger problem. The NO_EXPORT tag just makes it more complicated to get the "better paths" to the ISPs BGP customers. Adding unnecessary locks just to make something sound "safe" is usually a surefire way cause a disaster when a slightly-clued person clears the tag to get the routes to downstreams and suddenly discovers they are announcing your boxes routes to the world. Do you guys have a white paper on all this? Peter

cheers -- Sean

"Christopher A. Woodfield" wrote:

...

Can/will the box adjust inbound route selection via the use of prepending and/or provider communities?

-C

...

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

-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com

PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

www.xtns.net "New.Net on steroids" (ICANNWATCH.COM)

I believe they are just a licensee of RealNames. So while http://somedumbcompany.lame might work in Internet Explorer 5.0+ Try telnetting to somedumbcompany.lame:25. They won't get email, EVER. This company is even more bogus then new.net. At least new.net is /trying/ to use dns. -davidu

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tim Langdell Sent: Tuesday, August 21, 2001 8:01 AM To: nanog@merit.edu Subject: XTNS launch alternate domain name system

www.xtns.net

"New.Net on steroids" (ICANNWATCH.COM)

This company is even more bogus then new.net. At least new.net is /trying/ to use dns.

How unforunate it would be if they had a name space clash. -- Alex Bligh Personal capacity

On Tue, Aug 21, 2001 at 08:01:09AM -0700, Tim Langdell exclaimed:

www.xtns.net

"New.Net on steroids" (ICANNWATCH.COM)

http://www.xtns.net/code/technologemail.htm "At this time, XTNS Domain Namespaces are not supported by email and ftp client software." 'nuff said. This is no different than internet keywords, and likely to make about as big a splash. *zzzzz* -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m UNIX | IP networks | security | sysadmin | caffeine | BOFH | general geekery GPG public key 0xCB33CCA7 illum oportet crescere me autem minui