git: tcp: Balance aggressiveness of SACK rescue retransmission
sephe at crater.dragonflybsd.org
Thu Apr 26 01:41:45 PDT 2012
Author: Sepherosa Ziehau <sephe at dragonflybsd.org>
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