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    ..:||||||:..:||||||:..