git: tcp: Balance aggressiveness of SACK rescue retransmission

Sepherosa Ziehau sephe at
Thu Apr 26 01:41:45 PDT 2012

commit a098966f5a899988149ce42ce48446d59a94dd23
Author: Sepherosa Ziehau <sephe at>
Date:   Thu Apr 26 16:09:51 2012 +0800

    tcp: Balance aggressiveness of SACK rescue retransmission
    This commit is following the idea of sustain ACK clocking whenever
    possible to avoid timeout transmission during fast recovery, which
    is mentioned in both in RFC3517 and "Rescue Retransmission for SACK"
    - Be a little bit more aggressive in NextSeg()
      The main problem of "Rescue Retransmission for SACK" draft is its
      conservativeness of how many rescue retransmission could happen
      during fast recovery, which under some situation is not enough to
      sustain ACK clock.
      Our aggressive SACK rescue retransmission variant tries to tick out
      one rescue segment if there are no other segments could be sent according
      to the RFC3517, thus ACK clock is kept ticking.
    - Be consertive in sending out rescue segment.
      The idea of SACK rescue retransmission is just to sustain ACK clock.
      As long as there are segments sent (either new segments or retransmission)
      during SACK base fast recovery, the ACK clock will be sustained.  So
      rescue segment will not be sent in this situation.
    SACK rescue retransmission statistics are updated more accurately to
    reflect what had happened.
    The aggressive variant of SACK rescue retransmission could be disabled
    by setting sysctl net.inet.tcp.rescuesack_agg to 0; it is enabled by

Summary of changes:
 sys/netinet/tcp_input.c |   30 ++++++++++++++++++++++-
 sys/netinet/tcp_sack.c  |   60 +++++++++++++++++++++++++++++++++++++++-------
 sys/netinet/tcp_var.h   |    3 +-
 usr.bin/netstat/inet.c  |    5 +--
 4 files changed, 84 insertions(+), 14 deletions(-)

DragonFly BSD source repository

More information about the Commits mailing list