Hi Andre, >To answer your question: I do think we are fine with waiting for the >delayed ACK. If an application starts to seriously lag behind like >in your example the feedback mechanism should work and cause the sender >to slow down too. The feedback loop in TCP is not only the network but
The case I was thinking was not apps lagging behind on the read. The incoming packets got ahead and got dumped on the socket receive buffer before the app's blocked read could get scheduled by the OS and start reading the data. I am assuming the read needs the socket lock and it has to contend for this lock with the incoming packets. The stack may not have any control over when the read eventually gets to run. Suppose it runs after the 13th incoming packet got copied to the socket buffer and the window size is 13 MSS ? > > What's the purpose of the 2 MSS check by the way ? >This is part of the Silly Window Syndrome prevention. A good description is >here: Even without the 2 MSS check you are going to prevent SWS, isn't that right ? The other checks will make sure small window updates are not sent. Venkat ________________________________ From: Andre Oppermann <[EMAIL PROTECTED]> To: Venkat Venkatsubra <[EMAIL PROTECTED]> Cc: David Malone <[EMAIL PROTECTED]>; Rui Paulo <[EMAIL PROTECTED]>; Kevin Oberman <[EMAIL PROTECTED]>; freebsd-net@freebsd.org Sent: Monday, December 1, 2008 3:11:43 PM Subject: Re: FreeBSD Window updates Venkat Venkatsubra wrote: > Hi Andre, > > When delayed Ack is set the window update is not sent. > Does this mean when odd number of packets are received and later read, > a window update won't go out either till the next segment arrives or > 200 msecs delayed ack timer ? Can this reduced window block the sender from > sending the next segment that we are waiting for to open up the window ? Yes. The very idea of delayed ACK is to reduce the network utilization by ACKing only every other segment. Window updates should not override this as they currently do. Nagle comes into plays as well where we wait for the application to write something within the delayed ACK timeout to piggyback the answer together with the ACK (and window update). To answer your question: I do think we are fine with waiting for the delayed ACK. If an application starts to seriously lag behind like in your example the feedback mechanism should work and cause the sender to slow down too. The feedback loop in TCP is not only the network but also the sending and receiving application. In a normal bulk transfer where the receiving application services the receive buffer in regular intervals we update the window with every ACK. I'm open to other ideas if they fix the problem David is seeing without having more serious shortcomings. > What's the purpose of the 2 MSS check by the way ? This is part of the Silly Window Syndrome prevention. A good description is here: http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm PS: Attached is an updated version of the patch. The flag TF_DELACK can't be used to test for the presence of a delayed ACK. The presence of the delack timer has to be tested. -- Andre > Venkat > > > > ________________________________ > From: Andre Oppermann <[EMAIL PROTECTED]> > To: David Malone <[EMAIL PROTECTED]> > Cc: Rui Paulo <[EMAIL PROTECTED]>; freebsd-net@freebsd.org; Venkat > Venkatsubra <[EMAIL PROTECTED]>; Kevin Oberman <[EMAIL PROTECTED]> > Sent: Sunday, November 30, 2008 5:18:22 PM > Subject: Re: FreeBSD Window updates > > Andre Oppermann wrote: >> David Malone wrote: >>> I've got an example extract tcpdump of this at the end of the mail >>> - here 6 ACKs are sent, 5 of which are pure window updates and >>> several are 2us apart! >>> >>> I think the easy option is to delete the code that generates explicit >>> window updates if the window moves by 2*MSS. We then should be doing >>> something similar to Linux. The other easy alternative would be to >>> add a sysclt that lets us generate an window update every N*MSS and >>> by default set it to something big, like 10 or 100. That should >>> effectively eliminate the updates during bulk data transfer, but >>> may still generate some window updates after a loss. >> The main problem of the pure window update test in tcp_output() is >> its complete ignorance of delayed ACKs. Second is the strict 4.4BSD >> adherence to sending an update for every window increase of >= 2*MSS. >> The third issue of sending a slew of window updates after having >> received a FIN (telling us the other end won't ever send more data) >> I have already fixed some moons ago. >> >> In my new-tcp work I've come across the window update logic some time >> ago and backchecked with relevant RFCs and other implementations. >> Attached is a compiling but otherwise untested backport of the new logic. > > Slightly improved version attached. > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
