Routescience?

Peter Francis peter at softaware.com
Wed Aug 22 17:25:57 UTC 2001


At 4:32 PM +0000 8/22/01, E.B. Dreger wrote:
> > 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

>
>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 at brics.com>
>To: blacklist at 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 at brics.com>, or you are likely to be blocked.




More information about the NANOG mailing list