Re: Fix FRTO+NewReno problem (Was: Re: This has a work around)

["Damon L. Chesser" <damon@damtek.com>]

Ilpo Järvinen wrote:
> On Mon, 12 May 2008, Damon L. Chesser wrote:
>
>> Ilpo Järvinen wrote:
>> > On Mon, 12 May 2008, Damon L. Chesser wrote:
>> >
>> > > I applied the patches in order, no errors on that.  I compiled a 
>> stock
>> > > 2.4.24-1 kernel with the patches, I saw no errors there.
>> > >
>> > > booted into new kernel, printed with tcp_frto=0.  set tcp_frto =2,
>> > > restarted
>> > > the network (is this required, or is this a dynamic setting?), 
>> printed
>> > > from OO
>> > > document.  No joy.  tcpdump log attached (almost 15 min. worth of 
>> data)
>> > >
>> > > If you want, I can re-compile and double check for any 
>> compilation errors,
>> > > however, if there were any, it was not sever enough to stop the
>> > > compilation.
>> >
>> > On the bright side, the FRTO problem that was occuring previously 
>> is now
>> > fixed but there seems to be very few ways to communicate with that 
>> device
>> > sanely because it assumes in-order arrival and keeps discarding, as it
>> > seems, _all_ other segments... If you could try with this additional
>> > work-around attached (keep the fixes there as well). Turn
>> > tcp_frto_inorder_workaround sysctl to 1 before testing with FRTO.
>> >
>> > ...Can you please send a dump about working case too, this seems 
>> rather
>> > nasty device to work with (tcp_frto = 0 is enough to attain it, no 
>> need to
>> > have another kernel booted for that) and I'm interested to see what 
>> are the
>> > loss rates without FRTO...
>> >
>> >
>> New patch added in with the first two, tcp_frto_inorder_workaround =1 
>> test
>> printed 5 pages:  This worked.  Attached is the output of tcpdump.  Need
>> anything else?
>
> Thanks a lot for the testing & all. The picture is clear enough 
> already, so no additional help needed (I haven't yet looked the 
> non-frto dump but
> I doubt anything earth-shattering turns out, it's mostly interesting 
> for finding out how efficiently such network printer TCP can consume 
> segments it's receiving once FRTO related "fuzzy" ordering effects are 
> removed, for comparison purposes, mostly interesting and that's for hc 
> tcp guy like me :-)).
>
>
> Then one question for DaveM:
>
> What I'm not fully sure of, is do we want this workaround to be a 
> sysctl or unconditionally enabled which causes potentially up to two 
> unnecessary retransmissions? With SACK one or both of them will get 
> SACKed before they get retransmitted (both cases have common 
> scenarios). (I made that workaround patch for 2.6.24.1, so YMMV if you 
> just plainly try to apply it to net-2.6).
>
One more question from me, what release will we see these updates in, 
2.6.26?

-- 
Damon L. Chesser
damon@damtek.com
http://www.linkedin.com/in/dchesser