Date: Thu, 14 Mar 2013 18:32:17 +0530 From: Bejoy Thomas <bejoygthomas@yahoo.com> To: freebsd-net@freebsd.org Subject: Question regarding FreeBSD Congestion control Message-ID: <EE7BE1B3-8CD1-4899-AF80-B6ECEABD33B8@yahoo.com>
next in thread | raw e-mail | index | archive | help
I have been looking at the FreeBSD congestion control code and had some questions on the SACK enabled code flow .
With SACK the congestion window is retained as 1 MSS when the Fast Retransmit is exited and Fast Recovery is entered,so cwnd growth seems to be much slower than slow start, as we we are re transmitting drops from the sack hole or new data. But in non-SACK case the congestion window is restored to cwnd/2 +(dupacks-snd_limited)*MSS when Fast retransmit is exited as per RFC3782. Could some one familiar with the code please throw some light on why we fall back to a cwnd of 1MSS as we enter fast recovery with SACK enabled.
/*Congestion signal before ack. */
cc_cong_signal(tp, th, CC_NDUPACK);
cc_ack_received(tp, th, CC_DUPACK);
tcp_timer_activate(tp, TT_REXMT, 0);
tp->t_rtttime = 0;
if (tp->t_flags & TF_SACK_PERMIT) {
TCPSTAT_INC(
tcps_sack_recovery_episode);
tp->sack_newdata = tp->snd_nxt;
tp->snd_cwnd = tp->t_maxseg; <<<<<<<<<
(void) tcp_output(tp);
goto drop; <<<<<<<<<<
}
tp->snd_nxt = th->th_ack;
tp->snd_cwnd = tp->t_maxseg;
(void) tcp_output(tp);
KASSERT(tp->snd_limited <= 2,
("%s: tp->snd_limited too big",
__func__));
tp->snd_cwnd = tp->snd_ssthresh +
tp->t_maxseg *
(tp->t_dupacks - tp->snd_limited); <<<<<<<<<
Bejoy Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE7BE1B3-8CD1-4899-AF80-B6ECEABD33B8>