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

Leigh Porter leigh.porter at ukbroadband.com
Wed Jun 29 14:45:12 UTC 2011


> >
> >
> > 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 
______________________________________________________________________




More information about the NANOG mailing list