"Packet Shapers"

Sat Aug 1 20:03:24 UTC 1998

> >Yep.  Do you really see the market in providing just bigger IP cores,
> >though?  Only in that assumption, all value add is at the edge.
> I happen to
> >strongly disagree with that.
>
> i'm not stating that the value is only at the edge.  i'm stating that i
> don't think it is realistic to be sticking transparent devices that hold
> detailed state information on flows in the core.

>From a perspective within a TCP/IP core, a flow is a state generated by a
stream of packets which have one or more identifying characteristics in
common.  If you want to do anything in terms of flows or indentifying IP CoS
etc or perhaps gather statistics, you need to maintain some sort of state.
Perhaps not to make switching decisions right away, but at least collect the
state information and process it to then execute decisions down the road.

> there is enormous value in the core: some people get it right, some get it
> horribly wrong.  but lets face it - the core of a networks
> primary function
> is to move packets fast, and move them well.

I strongly disagree with that.  See other email that I had just sent.

> granted, they cannot appear on just any interface
> (serial/hssi/posip/atm/..)
> with just about any encapsulation - they are limited to
> fast/giga/ethernet -
> but this is also what i'm talking about deployment-at-edge.
> ... unless your border routers go posip/atm straight to your core routers?

They may.  If you look down the road at the next generation access
concentration, you may get exactly what you just described above.  I don't
want to restrict my core design _AND_ functionality implications based on my
reliance on Ethernet technology.  Ethernet is a cheap fast, mature local
area pipe at the moment.  Not a value add to my network.

> is there any reason why they can't look into provisioning/billing systems?
> its only a matter of some scripting glue . . .

What I have in the back of my mind goes far beyond what you can achieve with
scripting "glue".  Sure, you could write a wallstreet trading system in
Perl, but I wouldn't recommend it ;).

How about backoffice systems beyond the point of providing a reference to
devices in the network?

> the main point i was trying to make is this one anyway:
> >> i guess the point being that limitations were hit in the actual
> >> proxy-cache-
> >> boxes well before limitations were hit in layer-4 switch functionality.
> >> (biggest factor being: (total-transaction-time x trans-per-sec) >
> >> max-fd's).
>
> that is, well before you hit limitations on L4-type-devices in
> your network,
> you'll hit limitations in the devices that accept the redirected packets
> _from_ the L4 devices.

Hmm.

> this, in its own right, makes deploying in the core unworkable
> (....for the time being....).

You assume a particular technology/schematic model.  I don't think I see
that basis for your argument as a valid cornerstone of future network core
technology.

Cheers,
Chris

--
Christian Kuhtz, BellSouth Corp., Sr. Network Architect  <ck at bellsouth.net>
1100 Ashwood Parkway, Atlanta, GA 30338                        <ck at gnu.org>