Re: WCCP - cache only , no proxy

With Due respect to All of you as both are very much expert ppl . My opinion
is that WCCP cache method & Other Proxy cache methods are basically design
for different kind of network.

    I believe a Setup where we have multiple WAN and ASN, WCCP is a good
solution as we do not need to worry about the IP -Fragmentations or another
thing. WCCP is also reliable source for managing load balancing between
different bandwidths of download only options like

WCCP ROUTER/ACCESS SERVER

|

|

|

/ \

/ \

/ \

asymtric1 asymtric2

            Where as if you are using some method like just proxy settings
in client browser or using PAC files. you never lose your FTP traffic & many
other one.

        One Good way which I also used for long is make your Proxy as a
gateway and then enjoy. You can not only use squid for www but your own
written demons for irc/realplayer/443/icq etc..which can never think in WCCP
right now.:-)

        So its optional and depend on Network.:-))

With Regards
Ahsan Khan
Sr. System Admin
Internet Division (OneNet)
Sun Communication Pvt. Ltd.
Pakistan
http://www.one.net.pk

----- Original Message -----
From: "Lincoln Dale" <ltd@cisco.com>
To: "Henrik Nordstrom" <hno@hem.passagen.se>
Cc: <squid-users@ircache.net>
Sent: Thursday, April 20, 2000 1:38 AM
Subject: Re: WCCP - cache only , no proxy

> At 13:44 19/04/00, Henrik Nordstrom wrote:
> > > actually, no.
> > > there are other products in the marketplace which _do_ masquerade as
the
> > > client ip address when talking to web-servers.
> >
> >I was not talking about masquerading but TCP based redirection in
> >general. Such redirection requires that all traffic being redirected
> >passes thru the redirection point, and that no other communication is
> >taking place to the host being redirected/spoofed (i.e. origin web
> >server in WCCP). If other traffic are taking place then IP fragmentation
> >windows and other interesting TCP/IP aspects won't work reliably.
>
> not sure i agree with you entirely here.
> in theory, any form of fragmented IP packets may cause problems.
>
> in reality, this doesn't happen.
> remember that the _entire_ http flow, from initial SYN to the FIN/RST has
> been intercepted and redirected to a cache.
>
> providing the interception is as close as possible to the access-edge
> (customer), you don't really have a window-of-opportunity to get into IP
> Fragmentation issues.
>
> of course, i'm making an assumption that the cache's IP stack is capable
of
> negotiating suitable tcp-window-sizes (MSS) such that fragmentation won't
> occur.
>
> > > i'm merely pointing out that it was a conscious design decision NOT to
go
> > > down this path.
> >
> >And a very wise one I would say. Having dual redirection/masquerading is
> >a lot more complicated than only redirect/masquerade in one direction.
> >The basic problems are mostly the same, but the Internet is far more
> >diverse than the average dialup user..
>
> exactly.
>
> > > - due to the nature on it running in a router/switch, you can
typically
> > > perform the interception, even if traffic is not traversing a
> > > [fast|gigabit]
> > > ethernet.
> >
> >Who was talking about ethernet here? Yes, most of your competitors in
> >the redirection business are restricted to ethernet, but this has more
> >to do with the available products than the techniques as such.
>
> many customers networks don't actually have their traffic-flows passing
> thru an ethernet medium at convenient parts of the network.
>
> remember above that we want to perform interception/redirection as close
as
> possible to the user.
> the traffic medium on xDSL-type technologies is typically not ethernet at
> that point.
>
> >Btw, how does WCCP handle packet fragmenting in the data stream from the
> >client?
>
> WCCP doesn't handle it --
> the onus is on the network engineer to engineer a network where tcp
packets
> won't be fragmented between the user and the cache.
>
> given most people don't mess with MTUs these days, it isn't a
> problem. even if they do, the MSS negotiation in tcp will take care of
it.
> the only time it won't is if the service-provider's network has some hops
> with a lower MTU -- but why would one do that?
>
> > > here in the real world, the technique works, has been proven to scale
and
> > > is better than the alternatives.
> >
> >There are no fully deployable alternatives to TCP redirection at this
> >time, short of "manual" proxy configuration. Microsofts WPAD is a good
> >step in the right direction but have a number of issues mainly related
> >to security, and not being implemented in the bulk of the installed
> >browsers yet..
>
> .. and being less-than-great when you have churn in a network topology or
> network caches going into/out-of service.
>
> the WPAD stuff (imho) is more enterprise-like -- and less suitable for
> Service-Provider deployment.
>
> much of the elegance of transparent interception/redirection comes from
the
> fact that no user changes are required - and all software is immediately
> covered.
> also, the network folk are able to deploy caches of _other_ protocols
> seamlessly, and without every application having to be changed to support
it.
>
> yes, transparent interception/redirection isn't always perfect - with some
> better than others and able to dynamically "map out" when it is clearly
> breaking something.
>
> discussions of this type can typically move into discussions of layers 8
> and 9 (religion and politics).
> some people are diametrically opposed to any form of transparent
> interception/redirection.
> if deployed correctly, i bet those same people wouldn't even realise that
> it is taking place.
> (i not at Adelaide's IETF, many people wouldn't have realised that there
> was transparent caching taking place unless informed. the settings of the
> cache were also conservative in terms of ensuring freshness over
> maximising absolute hit-rate).
>
>
> cheers,
>
> lincoln.
>
> --
> Lincoln Dale Content Switching
> ltd@cisco.com Cisco Systems Inc. | |
> || ||
> +1 (408) 525-1274 bldg G, 170 West Tasman |||| ||||
> +61 (3) 9659-4294 << San Jose CA 95134 ..:||||||:..:||||||:..
>
Received on Thu Apr 20 2000 - 16:40:04 MDT