North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: "Packet Shapers"

  • From: Lincoln Dale
  • Date: Sat Aug 01 00:10:00 1998

In message <[email protected]>, "Christian Kuhtz" writes:
>> where they _do_ win, however, is at the access-router-edge of
>> your network.
>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.

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.

>True.  But, can they manage hundreds of pipes across an infrastructure?  Do
>they have the ability to tie into provisioning systems, billing systems etc?

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?

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

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.

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

>> (nb, yes, cisco do have WCCP - however, with it effectively being a
>> proprietary protocol, and whilst some of the functionality is possible in
>> policy-based-routing,
>Policy based routing is not what WCCP is about.  But I am glad Inktomi's (or
>whoever) drill worked on ya :).

<shrug>  its effectively dynamic-policy-based-routing on http flows.  i say
'dynamic', since cache-farm-participants can join/leave the policy.  if no
members are left in the farm, packets go down their natural path.

(.. and that isn't out of some other vendors' sales pitch either)