Comment 13 for bug 567394

Ok, I uploaded kernel packages to http://people.canonical.com/~smb/lp567394 for testing. I think one of the linux-image files should be sufficient, but I put headers up there just in case. There is a v1 and v2. As upstream was so very clear about what fixed the problem in there comments, v1 contains the following patches:

commit 99d737e98d81762332242cc82e5604520842911a
Author: Ilpo Järvinen <email address hidden>

    tcp FRTO: work-around inorder receivers

commit 59a16700219922a1b095abd76caa25fd4417470c
Author: Ilpo Järvinen <email address hidden>

    tcp FRTO: SACK variant is errorneously used with NewReno

commit 76ab0a7c88886400dd16870db65106215f3e4aa3
Author: Ilpo Järvinen <email address hidden>

    tcp FRTO: Fix fallback to conventional recovery

while v2 additionally has

commit 7a0c866aacab51afa7a6cbf6eccf5e1aa5fd64b9
Author: Ilpo Järvinen <email address hidden>

    tcp: Fix inconsistency source (CA_Open only when !tcp_left_out(tp))

So, if v1 fixes the issue we could go with the set of three (there has been another issue with F-RTO where I tried two of the patches and those did not seem to help), otherwise v2 or if even that does not help we can sit down and cry in despair.