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

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

From: David Miller <davem@davemloft.net>
Date: 2008-08-11 21:41:03
Also in: netfilter-devel

Possibly related (same subject, not in this thread)

From: Bill Fink <redacted>
Date: Fri, 8 Aug 2008 00:42:31 -0400
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.
This is the kind of direction I'm leaning towards as well.

The behavior of these middleboxes borders on unbelievable.  And there
comes a point where catering to these various busted boxes stops to
make sense.  At some point we have to say "sorry, someone has to get
that box fixed."

You can't reorder packets like that, on purpose, and not expect some
new, yet reasonable, TCP algorithm to fall flat on it's face.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help