]> git.karo-electronics.de Git - karo-tx-linux.git/commit
tcp FRTO: work-around inorder receivers
authorIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Tue, 13 May 2008 09:54:19 +0000 (02:54 -0700)
committerDavid S. Miller <davem@davemloft.net>
Tue, 13 May 2008 09:54:19 +0000 (02:54 -0700)
commit79d44516b4b178ffb6e2159c75584cfcfc097914
tree4721a8524c40452835018d315f80d2abc46e0d24
parenta1c1f281b84a751fdb5ff919da3b09df7297619f
tcp FRTO: work-around inorder receivers

If receiver consumes segments successfully only in-order, FRTO
fallback to conventional recovery produces RTO loop because
FRTO's forward transmissions will always get dropped and need to
be resent, yet by default they're not marked as lost (which are
the only segments we will retransmit in CA_Loss).

Price to pay about this is occassionally unnecessarily
retransmitting the forward transmission(s). SACK blocks help
a bit to avoid this, so it's mainly a concern for NewReno case
though SACK is not fully immune either.

This change has a side-effect of fixing SACKFRTO problem where
it didn't have snd_nxt of the RTO time available anymore when
fallback become necessary (this problem would have only occured
when RTO would occur for two or more segments and ECE arrives
in step 3; no need to figure out how to fix that unless the
TODO item of selective behavior is considered in future).

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Reported-by: Damon L. Chesser <damon@damtek.com>
Tested-by: Damon L. Chesser <damon@damtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv4/tcp_input.c