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 <000a01bdbc95$d2bc59b0$2b0698cd@oreo.eng.bellsouth.net>, "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?
>Nope.

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)


cheers,

lincoln.