1. 14 May, 2008 5 commits
  2. 13 May, 2008 3 commits
    • Ilpo Järvinen's avatar
      tcp FRTO: work-around inorder receivers · 79d44516
      Ilpo Järvinen authored
      
      
      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: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Reported-by: default avatarDamon L. Chesser <damon@damtek.com>
      Tested-by: default avatarDamon L. Chesser <damon@damtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79d44516
    • Ilpo Järvinen's avatar
      tcp FRTO: Fix fallback to conventional recovery · a1c1f281
      Ilpo Järvinen authored
      It seems that commit 009a2e3e
      
       ("[TCP] FRTO: Improve
      interoperability with other undo_marker users") run into
      another land-mine which caused fallback to conventional
      recovery to break:
      
      1. Cumulative ACK arrives after FRTO retransmission
      2. tcp_try_to_open sees zero retrans_out, clears retrans_stamp
         which should be kept like in CA_Loss state it would be
      3. undo_marker change allowed tcp_packet_delayed to return
         true because of the cleared retrans_stamp once FRTO is
         terminated causing LossUndo to occur, which means all loss
         markings FRTO made are reverted.
      
      This means that the conventional recovery basically recovered
      one loss per RTT, which is not that efficient. It was quite
      unobvious that the undo_marker change broken something like
      this, I had a quite long session to track it down because of
      the non-intuitiviness of the bug (luckily I had a trivial
      reproducer at hand and I was also able to learn to use kprobes
      in the process as well :-)).
      
      This together with the NewReno+FRTO fix and FRTO in-order
      workaround this fixes Damon's problems, this and the first
      mentioned are enough to fix Bugzilla #10063.
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Reported-by: default avatarDamon L. Chesser <damon@damtek.com>
      Tested-by: default avatarDamon L. Chesser <damon@damtek.com>
      Tested-by: default avatarSebastian Hyrwall <zibbe@cisko.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a1c1f281
    • David S. Miller's avatar
  3. 12 May, 2008 32 commits