I believe that this will only effect data flowing toward the router (as a host) and not data passing through the router. for this to give us the desired effect (the one that we all want!) we would need to have a proxy on one or both sides of the WAN link, depending on where we want to adjust the TCP Window.
For the router to do this, it would need to rewrite the TCP header, then recalculate the checksum, and ship out the packet. If this is what was actually done, I would think that Cisco would make a big deal out of this (because it WOULD be a big deal).
Some "WAN Optimization" appliances that actually do things like this include Netscaler and Steelhead devices ($$$).
The CSS devices have a feature like this that apparently only works for HTTP. Why they limit this to HTTP, I don't know.
I actually have worked with out server group in the past to tune a Netapp iSCSI connection across a 15Mbps ATM link (minus cell tax something like 13.5Mbps). We had some pretty serious sawtoothing pre-adjustment, but after adjusting the TCP Window size on both ends, we were able to take full advantage of the WAN link. That is want I consider network engineering, and why we cannot just throw bandwidth at issues.
I would like to see Cisco do something with CSS to make TCP scaling work as a proxy for any TCP app. Maybe I will have to make a feature request!
