[c-nsp] WCCPv2 - what happens to existing connections when redirect-list is modified?

[Geoffrey Pendery]

"thus, to answer your question, anything that was previously eligable
for optimization which now is forwarded rather than redirected (due to
your redirect-list) will hit #3.  for other traffic which may be sent
to the WAAS box but where WAAS decides its not worthwhile doing
anything with, will likely have #2 apply."

I believe that the WAAS boxes also alter some of the TCP attributes
(like jumping the SEQ number way up when it enters the local WAAS,
then dropping it back down when it leaves the remote WAAS) in such a
way that, if one WAAS box suddenly disappears from the path, your TCP
session is going down, whether it was being properly optimized or not.
 They have to do this sort of thing, not just to optimize, but to
recognize each other:  If I'm "core WAAS", and I see a new TCP conn
come in, I need to know just by looking at this conn whether it's
coming from another WAAS or just an end host.  So if I'm taking a new
conn from an end host, when I pass it on I need to modify it so that
other WAASes (WAASi?  WAASen?  ouch.) know that I'm out there.

In other words, there is no scenario #2, ever.
I think the answer is pretty much #3 across the board.

As always though - someone jump in and correct me if I'm wrong here.


-Geoff


On Thu, May 21, 2009 at 11:58 PM, Lincoln Dale <ltd at cisco.com> wrote:
> Dale Shaw wrote:
>>
>> Hi all,
>>
>> Scenario: WCCPv2 configured and active for WAAS, all TCP traffic
>> redirected (no redirect-list configured for service groups 61 and 62)
>>
>> What happens to active/existing TCP sessions that _are_ being
>> intercepted/redirected if I configure a redirect-list with a 'deny'
>> statement that matches the session?
>>
>> I'm not intimately familiar with WCCPv2 operation but I assume these
>> are the possibilities:
>>
>> 1) existing connections are not affected and continue to be
>> intercepted/redirected in spite of ACL; new connections are not
>> intercepted/redirected; WCCP is smart!
>> 2) new packets for existing connections stop being
>> intercepted/redirected and are routed normally - TCP copes OK and
>> sessions stay up; TCP is amazing!
>> 3) as above, but TCP does not cope, as SEQs/ACKs etc. change; sessions
>> are torn down/time out; TCP is only human
>> 4) something else :-)
>>
>> Can anyone provide any insight?
>>
>
> some of the magic voodoo stuff that WAAS does is outlined in a high level at
> http://www.cisco.com/en/US/prod/collateral/contnetw/ps5680/ps6870/prod_white_paper0900aecd8051c11d.html
>
> basically, there are multiple things going on here:
> - TFO means that even if the host initiating a TCP connection doesn't use
> large windows, SACK and other go-fast TCP options, TFO will do that for you.
>  that in itself implies that the TCP connection established by the original
> host will NOT be the one that the end host sees (even though it may seem to
> originate from the same ip-address as that of the original host)
> - DRE means that not all the data necessarily goes over the WAN either.
> - what goes over the WAN may also have LZ compression applied to it too.
>
> so, suffice to say, there will be significant differences "pre-optimized"
> and "post-optimized" for traffic which is elegible for acceleration.
>
> thus, to answer your question, anything that was previously eligable for
> optimization which now is forwarded rather than redirected (due to your
> redirect-list) will hit #3.
> for other traffic which may be sent to the WAAS box but where WAAS decides
> its not worthwhile doing anything with, will likely have #2 apply.
>
>
> the underlying design of WCCP is that the network doesn't maintain "flow
> state".  but that isn't to say that there aren't methods of WCCP utilizing
> "flow acceleration" aspects of netflow-capable router/switch platforms.
> but generally speaking, in this modern day & age, "flow switching" is
> frowned upon, doesn't scale, and otherwise considered not worthwhile except
> purely as an accounting mechanism only.
>
>
> cheers,
>
> lincoln.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>