On Sun, 2005-08-21 at 01:53 -0700, Wael Noureddine wrote: > >> How do you intend on avoiding huge stretch ACKs? > > > > The implication is that stretch ACKs are bad, which is wrong. > > Oh yes, that's right, you're the same person who earlier in this > > thread tried to teach us that bursty TCPs are non-standard :-) > > Are you saying that burstiness is not an issue? > There is a disconnect here and that's because you're focusing on the end > host and ignoring the network. > > > Stretch ACKs are actually a positive thing on a healthy connection and > > do indeed help the sender. And when loss events occur, LRO stops > > immediately and delivers the packets as-is so that loss information > > via ACKs with SACK blocks can immediately make their way to the > > sender. > > Burstiness is intrinsic to LSO/LRO and they thrive on it, there is no doubt > about that. However, breaking congestion control principles should not be > taken lightly and concerns need to be addressed in a convincing matter, no > handwaving.
All other things being equal, it is better not to put packets into the network faster than it can drain them out. Large bursts increase delay variation, and increase the probability that two or more packets in a connection will be dropped within an RTT (not every box is implementing AQM yet). New 10Gig-switch-on-a-chip devices like Fujitsu's MB87Q3140 (http://www.fujitsu.com/us/services/edevices/microelectronics/networkingassps/mb87q3140/) have only limited on-chip buffer memory. So transmit packet pacing is preferred; see http://yuba.stanford.edu/~yganjali/research/publications/Very-Small-Buffers-CCR.pdf for further arguments. With that being said, I don't see why transmit packet pacing cannot be implemented as part of LSO, without introducing lots of invasive changes in the stack. Regards, // Steve - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
