On Tuesday, 2002/03/05 at 08:42 ZE2, Hank Nussbacher <hank@att.net.il> wrote:
New 12.2(8)T feature in Cisco IOS called TCP Windows Scaling:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122...
2t8/tcpwslfn.htm
Specifically made for satellite networks: ip tcp window-size 750000
I don't understand the benefit of this on a router. Except for connections where the router itself is an endpoint (telnet to the router, for example), the router has no need to even be aware of window size. Perhaps the router's window size comes into play if the router is performing advanced functions such as NAT or IPSEC? Tony Rall
Tony Rall wrote:
Specifically made for satellite networks: ip tcp window-size 750000
I don't understand the benefit of this on a router. Except for connections where the router itself is an endpoint (telnet to the router, for example), the router has no need to even be aware of window size.
Perhaps the router's window size comes into play if the router is performing advanced functions such as NAT or IPSEC?
I don't expect the router would do anything in the NAT case, but a transparent proxy used to work magic in the satellite days in Australia (before Southern Cross). A SOCKS proxy would do the same but be far more intrusive. Basically a customer accessing a US web site ends up looking like this (many hops deliberately missed): DIAL CUSTOMER (customer tcp stack) | medium latency hop (modem) | layer 4 switch or router with WCCP or policy routing | PROXY FARM (good tcp stack with good window sizes) | high latency hop (satellite) | US internet | US WEBSITE (server tcp stack) Often the server TCP stack and the customer TCP stack may be dodgy and sometimes even unable to directly communicate, but the good TCP stack in the middle can communicate to both of the dodgy TCP stacks at either end as well as providing a good window size to receive from the server and splitting the latency in half on each TCP connection leg as to a direct connection. David. -- David Luyer Phone: +61 3 9674 7525 Network Development Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 BYTE http://www.pacific.net.au/ NASDAQ: PCNTF
On Wednesday, March 6, 2002, at 12:53 AM, David Luyer wrote:
Often the server TCP stack and the customer TCP stack may be dodgy and sometimes even unable to directly communicate, but the good TCP stack in the middle can communicate to both of the dodgy TCP stacks at either end as well as providing a good window size to receive from the server and splitting the latency in half on each TCP connection leg as to a direct connection.
Putting a cache on the US side and using it to feed the cache in the Pacific was also something that I heard about people doing -- that way you got to fine-tune the TCP stacks either side of the satellite circuit, and the customer and origin server TCP stacks only needed to be tuned for cross-country latency. Depending on your caches, you might also be able to use a pool of persistent HTTP connections between the caches to avoid per-connection TCP setup latency. Similar pairs of caches could be used either side of sub-1500-byte-MTU access circuits to eliminate path MTU discovery failures due to poorly configured firewalls, which sounds like it should be useful when your trans-Pacific bandwidth comprises some hideous mixture of unidirectional satellite and GRE tunnels, not that I would know of course. Joe
participants (3)
-
David Luyer -
Joe Abley -
Tony Rall