Date: Fri, 25 Jan 2013 10:27:51 +1100 From: Lawrence Stewart <lstewart@freebsd.org> To: Andre Oppermann <oppermann@networx.ch> Cc: freebsd-net@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: Some questions about the new TCP congestion control code Message-ID: <5101C377.7010907@freebsd.org> In-Reply-To: <51014150.50101@networx.ch> References: <201301141604.29864.jhb@freebsd.org> <50F5137F.1060207@freebsd.org> <201301151427.50932.jhb@freebsd.org> <51013702.8040707@freebsd.org> <51014150.50101@networx.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/25/13 01:12, Andre Oppermann wrote: > On 24.01.2013 14:28, Lawrence Stewart wrote: >> On 01/16/13 06:27, John Baldwin wrote: >>> One other thing I noticed which is may or may not be odd during this, >>> is that >>> if you have a connection with TCP_NODELAY enabled and you fill your >>> cwnd and >>> then you get an ACK back for an earlier small segment (less than >>> MSS), TCP >>> will not send out a "short" segment for the amount of window space >>> released. >>> Instead, it will wait until a full MSS of space is available before >>> sending >>> a packet. I'm not sure if that is the correct behavior with >>> TCP_NODELAY or >>> if we should send "short" segments in that case. >> >> We try fairly hard not to send runt segments irrespective of NODELAY, >> but I would be happy to see that change. I'm not aware of any "correct >> behaviour" we have to adhere to - I think it would be perfectly >> reasonable to have a sysctl set the lowest number of bytes we'd be >> willing to send a runt segment for and then key off TCP_NODELAY as to >> whether we try hard to send an MSS worth or send as soon as we have the >> min number of bytes worth of window available. > > This is classic silly window syndrome prevention applied to the CWND. Yes, but I think we could provide knobs to relax the behaviour where the latency vs header/payload overhead tradeoff swings in favour of latency. I guess, John, I should first ask if you know why you were only getting such small ACKs back? Were you sending full MSS segments in the first place or doing some sort of PUSH to try and expedite getting some smaller chunk of data to the other end which triggered a small segment and corresponding small ACK? > Sending a small segment when the window opens just a bit isn't going to help > much and I wouldn't be game to make such a blanket statement - that very much depends on the situation. I think John's use case is relevant and we currently aren't very helpful towards it. > mostly clogs the network. How so? We're not in the 80's any more. If I pay for X MBps of service, I expect to be able to use it in any way I choose. Packet size is irrelevant, but there are obvious efficiencies to be gained by maximising the amount of payload in each segment. > This is actually a side effect of ABC (appropriate byte counting) where not > the ACK's are counted but the bytes ACK'ed. Disabling ABC will solve this > problem. I don't follow. How is what John described above related to ABC? Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5101C377.7010907>