Date: Thu, 11 Aug 2011 23:33:37 +1000 From: Lawrence Stewart <lstewart@freebsd.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Steven Hartland <killing@multiplay.co.uk>, Andre Oppermann <andre@freebsd.org>, freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? Message-ID: <4E43DA31.7000605@freebsd.org> In-Reply-To: <20110811123102.GQ94016@zxy.spb.ru> References: <E18D678F05BB4F3B93ADEB304CCA8504@multiplay.co.uk> <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk> <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <C706DEE346684B8DB06CFC090F556E72@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru> <4E4330B5.5030100@freebsd.org> <20110811123102.GQ94016@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/11/11 22:31, Slawa Olhovchenkov wrote: > On Thu, Aug 11, 2011 at 11:30:29AM +1000, Lawrence Stewart wrote: > >> On 08/05/11 16:57, Slawa Olhovchenkov wrote: >>> On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote: >> [snip] >>>> >>>> The real fix which is somewhere down on my todo list is to make all >>>> these memory constraints elastic and respond to VM pressure, thus >>>> negating the need for a hard limit at all. This would solve many if not >>>> most of the TCP tuning problems we currently have with one foul swoop >>>> and would greatly reduce the need for tuning in many situations that >>>> currently are in the "needs manual tuning" basket. >>> >>> Autotunig w/o limits is bad idea. This is way to DoS. >> >> Depends how it is implemented. With appropriate backpressure mechanisms >> put in place, it could be perfectly safe. I envisage reassembly segments >> being at the bottom of the heap in terms of importance, so if a machine >> were to come under memory pressure, they would be the first thing to be >> reclaimed. TCP would continue to operate if they got pulled out from >> under the connection as the protocol doesn't consider segments held in >> reassembly to have been delivered, so would recover via retransmission. > > Yes, TCP would continue to operate. But attacker don't allow to put > system under memory pressure. Without a concrete patch to discuss, let's just agree to disagree for the time being. FreeBSD does a fairly good job autoscaling and reacting to pressure with the VM subsystem for example. I don't see why we can't become good at doing it with the netstack. Manual tuning sucks and can be just as dangerous if you tune things up to get performance, which opens you up to the same problems. >>> May be solved this trouble by preallocation "hidden" element in tqe >>> for segment received in valid order and ready for send to application? >>> T.e. when creating reassembled queue for tcp connection we allocation >>> queue element (with room for data payload), used only when data ready >>> for application. Allocation in queue for not breaking ABI (don't >>> change struct tcpcb). >> >> I'm not sure I quite follow what you're suggesting here, but I think >> Andre's proposed patch achieves the same goal and is arguably cleaner? > > Ande allocation on stack. My idea is different (sorry for bad english). > > 1. application open socket. > 2. kernel allocated internal tcp structure for this socket. > 2.1 additional step: kernel beforehand allocation one tseg_qent and > place it in t_segq. this queue entry will be used only when we receive > first good segment in right place. > > for example: > > [lost segment 100] (segment 101) (segment 102) ... (segment 100). > > segments 101, 102 and etc processed as usaly. > segment 100 placed in reserved and previously allocated queue entry. > > after receive segment 100 we can send data to application (to user > space). after send data queue entry from 2.1 not freed, this > permanently allocated entry. Ok I understand. Why is your proposal better than stack allocated though? I can think of a number of reasons why it's worse... Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E43DA31.7000605>