[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: IPv6 adoption

Eray Ozkural wrote:
> ----- Original Message -----
> From: "Tomasz Wegrzanowski" <maniek@beer.com>
> To: "Sean Reifschneider" <jafo@tummy.com>
> Cc: "LOSURS Discussion List" <discuss@losurs.regina.sk.ca>; "Debian
> Developers' Mailing List" <debian-devel@lists.debian.org>
> Sent: Saturday, July 15, 2000 10:37 PM
> Subject: Re: IPv6 adoption
> > On...Why not
> > > go with dynamic-sized addresses, if you really want to be future-proof?
> >
> > Am I the only one who think than 128-bit was chosen, because
> > IETF tought that at time when Internet will be based on IPv6,
> > most computers will be 128-bit ?
> Oh god, that must be right. IETF must be dominated by EE people, the average
> CS guy wouldn't mind having a variable number of bits for the address :)

TCP/IP has always been dominated by EE types, while OSI has been
by management/marketing types, according to the most repeated
CS is the intersection | union of these, depending on your point of

> > Dynamic-sized addresses would twice requirements for routers CPU,
> > and they don't align well.

> Why not? the router's CPU wouldn't have much trouble decoding the address
> given the quite capable CPUs now... And if you want high capacity,
> go for parallel stuff, that's why we're trying to push more parallel
> prog. stuff. :) IMHO, thinking at
> the hardware level is not always the brightest way to approach a problem.

Current routers do not do things "in hardware", but in RAM, with the OS
loaded from Flash/EEPROM.  They are merely special-purpose computers.
If I recall accurately, the last Cisco 2500 I had open was based on
a 68030.  We're not forgetting the routing capabilities of Linux, are

> I mean, EE people thought they could solve the speech recognition problem
> with a bunch of NN chips or some FFTs followed by a naive stochastics model...
> But where are they now? He he...

Hmmm...  So, anyway, with dynamic-sized addresses, you have to have
some way for the processor (program, not "chip") to know what the size
is, so you'd either have to send the size first, or have an 'End of
code, that would cut into your potential code space.  Seems inefficient.
Less processing needed = more packets put through.  Use your parallel
processing to push more packets through, less whatever is filtered out.

Bolan.Meek@wcom.com 972-729-5387
bolan@koyote.com (home phone on request)
RE: xmailtool http://www.koyote.com/users/bolan/xmailtool/index.html
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public

Reply to: