[26191] in North American Network Operators' Group
Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
daemon@ATHENA.MIT.EDU (Randy Bush)
Wed Dec 8 18:11:20 1999
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Dan Foster <dsf@gblx.net>
Cc: Tim Wolfe <tim@clipper.net>, Vijay Gill <wrath@cs.umbc.edu>,
NANOG <nanog@merit.edu>
Message-Id: <E11vqD7-00013f-00@rip.psg.com>
Date: Wed, 08 Dec 1999 15:09:25 -0800
Errors-To: owner-nanog-outgoing@merit.edu
>>> Full route table size is not a problem. You can burn a hard disk as you
>>> mentioned to store it. The issue is getting data in and out of the
>>> processor, i.e. number of pins. Core flows are not ameneable to caching.
>>> This approach will fail the first time you see a new packet and need to
>>> swap from hard disk.
>> Not that it would be very economical, but what are the technical
>> implications of using a solid state device (such as the Quantum's
>> RUSHMORE NTE series) instead of a normal hard drive?
> Interesting question... even though it's significantly faster than an hard
> drive, it does have some inherent bottlenecks such as a maximum number of
> operations per second which might be a little stifling on a backbone core
> router :) Still, I've never actually tried *that*, so don't know for sure.
>
> There's also latency in other areas - that leads me to think that regular
> memory is still faster. Finally, it would be attached to the host system
> through a bus (SCSI, whatever) that's a lot slower than the internal
> memory bus.
>
> These kinds of devices tend to be a better fit for systems that doesn't
> have extreme time limitations on processing data such as for mail spool
> files, etc.
reality check:
if you had 100TB of on-ASIC SRAM you would still be screwed. you can't
afford the PER-PACKET LATENCY of telco number style portability REFERRAL.
once again: ip is a connectionless protocol. each packet is potentially a
new route.
telcos don't mind a second or two in call setup, because it is CALL SETUP,
not 42 times a second.
[ credit scott bradner for making this quite clear even to me in some ietf
bar ]
randy
