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

["Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2464 bytes --]

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).

-- 
 i.