nanog mailing list archives

RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)


From: Leigh Porter <leigh.porter () ukbroadband com>
Date: Wed, 29 Jun 2011 14:45:12 +0000



Well, then you run into the nice problem of the RNCs only having 400
kilobytes of buffers per session and will drop packets if they receive
more
packets than that, or sometimes even just because they receive a burst
of a
few tens of packets at GigE linerate (because the customer with large
TCP
window size is talking to a GigE connected server).

The recommended "solution" from the vendor was to tune the client to
a
smaller TCP window size so that their RNC wouldn't get such a large
burst.

*sigh*


Sounds like a vendor specific issue :(

Good tcp vs default tcp will not close the window tight due to some
ephemeral loss or delay.  The penalties are generally too strong in tcp
for
the issues of delay and loss in 3g ... this is one of the main selling
points for tcp proxies .... but better done with modern tcp on the
clients
instead of a middle box

Indeed it does sound like a vendor issue. The network I was running did just fine with the FastSoft proxy boxes. In 
fact, they were so effective that we almost doubled our TCP throughput overnight! We did not quite get a chance to 
explore the interaction between the TCP proxies and the algorithms that supposedly fixed TCP in the vendors GGSN (TCP 
window size fiddling) and the interaction of the new TCP protocol with the 3G base station scheduler, but the results 
kind of spoke for themselves really.

Similarly we have had good results with WiMAX networks.


--
Leigh Porter
UK Broadband







______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


Current thread: