Thread (105 messages) 105 messages, 7 authors, 2008-09-22

Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

From: Bill Fink <hidden>
Date: 2008-08-08 04:42:31
Also in: netfilter-devel

Possibly related (same subject, not in this thread)

On Thu, 7 Aug 2008, Ilpo Järvinen wrote:
On Wed, 6 Aug 2008, Dâniel Fraga wrote:
quoted
On Thu, 31 Jul 2008 15:47:55 +0200
Thomas Jarosch [off-list ref] wrote:
quoted
If your problem is really FRTO related (that what the patch is for),
you could try to disable FRTO temporarily:
	Hi, the patch helped, but what's the conclusion? Is the problem
"solved"? Will this patch be merged in the next kernel? This thread
seems to be forgotten.
...Dave, I think we should probably put this FRTO work-around to net-2.6 
and -stable to remain somewhat robust (it's currently worked around only 
for newreno anyway). ...But I leave the final decision up to you.
Since you suspect the problem is being caused by a broken middlebox,
would it perhaps be a better approach to add a per-route option to
allow disabling of FRTO for the given destination.  This would be
similar to Stephen Hemminger's fix for broken middleboxes that don't
handle window scaling properly.  It seems this would be better than
modifying FRTO behavior for everyone else that is being compliant.

A question then arises is if the bogus scenario has a TCP signature
that could be used to print a warning message for the unsuspecting
user so they could then take necessary corrective action.

						-Bill
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help