From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Fri, 16 Mar 2007 20:41:06 +0200
> Many assumptions that are true when no reordering or other > strange events happen are not a part of the RFC3517. FACK > implementation is based on such assumptions. Previously (before > the rewrite) the non-FACK SACK was basically doing fast rexmit > and then it times out all skbs when first cumulative ACK arrives, > which cannot really be called SACK based recovery :-). > > RFC3517 SACK disables these things: > - Per SKB timeouts & head timeout entry to recovery > - Marking at least one skb while in recovery (RFC3517 does this > only for the fast retransmission but not for the other skbs > when cumulative ACKs arrive in the recovery) > - B & C flavors of loss detection (see comment before > tcp_sacktag_write_queue) > > This does not implement the "last resort" rule 3 of NextSeg, which > allows retransmissions also when not enough SACK blocks have yet > arrived above a segment for IsLost to return true [RFC3517]. > > The implementation differs from RFC3517 in two points: > - Rate-halving is used instead of FlightSize / 2 > - Instead of using dupACKs to trigger the recovery, the number > of SACK blocks is used as FACK does with SACK blocks+holes > (which provides more accurate number). It seems that the > difference can affect negatively only if the receiver does not > generate SACK blocks at all even though it claimed to be > SACK-capable. > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> I'm OK with this one too, applied, thanks a lot! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
