1. 17 Jun, 2006 34 commits
  2. 12 Jun, 2006 1 commit
  3. 11 Jun, 2006 1 commit
    • Aki M Nyrhinen's avatar
      [TCP]: continued: reno sacked_out count fix · 79320d7e
      Aki M Nyrhinen authored
      From: Aki M Nyrhinen <anyrhine@cs.helsinki.fi>
      IMHO the current fix to the problem (in_flight underflow in reno)
      is incorrect.  it treats the symptons but ignores the problem. the
      problem is timing out packets other than the head packet when we
      don't have sack. i try to explain (sorry if explaining the obvious).
      with sack, scanning the retransmit queue for timed out packets is
      fine because we know which packets in our retransmit queue have been
      acked by the receiver.
      without sack, we know only how many packets in our retransmit queue the
      receiver has acknowledged, but no idea which packets.
      think of a "typical" slow-start overshoot case, where for example
      every third packet in a window get lost because a router buffer gets
      with sack, we check for timeouts on those every third packet (as the
      rest have been sacked). the packet counting works out and if there
      is no reordering, we'll retransmit exactly the packets that were 
      without sack, however, we check for timeout on every packet and end up
      retransmitting consecutive packets in the retransmit queue. in our
      slow-start example, 2/3 of those retransmissions are unnecessary. these
      unnecessary retransmissions eat the congestion window and evetually
      prevent fast recovery from continuing, if enough packets were lost.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 05 Jun, 2006 1 commit
    • Herbert Xu ~{PmVHI~}'s avatar
      [TCP]: Avoid skb_pull if possible when trimming head · f2911969
      Herbert Xu ~{PmVHI~} authored
      Trimming the head of an skb by calling skb_pull can cause the packet
      to become unaligned if the length pulled is odd.  Since the length is
      entirely arbitrary for a FIN packet carrying data, this is actually
      quite common.
      Unaligned data is not the end of the world, but we should avoid it if
      it's easily done.  In this case it is trivial.  Since we're discarding
      all of the head data it doesn't matter whether we move skb->data forward
      or back.
      However, it is still possible to have unaligned skb->data in general.
      So network drivers should be prepared to handle it instead of crashing.
      This patch also adds an unlikely marking on len < headlen since partial
      ACKs on head data are extremely rare in the wild.  As the return value
      of __pskb_trim_head is no longer ever NULL that has been removed.
      Signed-off-by: default avatarHerbert Xu ~{PmV&gt;HI~} <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 02 Jun, 2006 1 commit
  6. 28 May, 2006 2 commits