Date: Sun, 23 Aug 2020 19:56:45 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: Liang Tian <l.tian.email@gmail.com>, FreeBSD Transport <freebsd-transport@freebsd.org> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: RE: Fast recovery ssthresh value Message-ID: <SN4PR0601MB3728D1F8ABC9C86972B6C53886590@SN4PR0601MB3728.namprd06.prod.outlook.com> In-Reply-To: <CAJhigrhbguXQzeYGfMtPRK03fp6KR65q8gjB9e9L-5tGGsuyzQ@mail.gmail.com> References: <CAJhigrhbguXQzeYGfMtPRK03fp6KR65q8gjB9e9L-5tGGsuyzQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Liang,
In SACK loss recovery, you can recover up to ssthresh (prior cwnd/2 [or 70%=
in case of cubic]) lost bytes - at least in theory.
In comparison, (New)Reno can only recover one lost packet per window, and t=
hen keeps on transmitting new segments (ack + cwnd), even before the receip=
t of the retransmitted packet is acked.
For historic reasons, the semantic of the variable cwnd is overloaded durin=
g loss recovery, and it doesn't "really" indicate cwnd, but rather indicate=
s if/when retransmissions can happen.
In both cases (also the simple one, with only one packet loss), cwnd should=
be equal (or near equal) to ssthresh by the time loss recovery is finished=
- but NOT before! While it may appear like slow-start, the value of the cw=
nd variable really increases by acked_bytes only per ACK (not acked_bytes +=
SMSS), since the left edge (snd_una) doesn't move right - unlike during sl=
ow-start. But numerically, these different phases (slow-start / sack loss-r=
ecovery) may appear very similar.
You could check this using the (loadable) SIFTR module, which captures t_fl=
ags (indicating if cong/loss recovery is active), ssthresh, cwnd, and other=
parameters.
That is at least how things are supposed to work; or have you investigated =
the timing and behavior of SACK loss recovery and found a deviation to RFC3=
517? Note that FBSD currently has not fully implemented RFC6675 support (wh=
ich deviates slightly from 3517 under specific circumstances; I have a patc=
h pending to implemente 6675 rescue retransmissions, but haven't tweaked th=
e other aspects of 6675 vs. 3517.
BTW: While freebsd-net is not the wrong DL per se, TCP, UDP, SCTP specific =
questions can also be posted to freebsd-transport, which is more narrowly f=
ocused.
Best regards,
Richard Scheffenegger
-----Original Message-----
From: owner-freebsd-net@freebsd.org <owner-freebsd-net@freebsd.org> On Beha=
lf Of Liang Tian
Sent: Sonntag, 23. August 2020 00:14
To: freebsd-net <freebsd-net@freebsd.org>
Subject: Fast recovery ssthresh value
NetApp Security WARNING: This is an external email. Do not click links or o=
pen attachments unless you recognize the sender and know the content is saf=
e.
Hi all,
When 3 dupacks are received and TCP enter fast recovery, if SACK is used, t=
he CWND is set to maxseg:
2593 if (tp->t_flags & TF_SACK_PERMIT) {
2594 TCPSTAT_INC(
2595 tcps_sack_recovery_episode);
2596 tp->snd_recover =3D tp->snd_nxt;
2597 tp->snd_cwnd =3D maxseg;
2598 (void) tp->t_fb->tfb_tcp_output(tp);
2599 goto drop;
2600 }
Otherwise(SACK is not in use), CWND is set to maxseg before
tcp_output() and then set back to snd_ssthresh+inflation
2601 tp->snd_nxt =3D th->th_ack;
2602 tp->snd_cwnd =3D maxseg;
2603 (void) tp->t_fb->tfb_tcp_output(tp);
2604 KASSERT(tp->snd_limited <=3D 2,
2605 ("%s: tp->snd_limited too big",
2606 __func__));
2607 tp->snd_cwnd =3D tp->snd_ssthresh +
2608 maxseg *
2609 (tp->t_dupacks - tp->snd_limited);
2610 if (SEQ_GT(onxt, tp->snd_nxt))
2611 tp->snd_nxt =3D onxt;
2612 goto drop;
I'm wondering in the SACK case, should CWND be set back to ssthresh(which h=
as been slashed in cc_cong_signal() a few lines above) before line 2599, li=
ke non-SACK case, instead of doing slow start from maxseg?
I read rfc6675 and a few others, and it looks like that's the case. I appre=
ciate your opinion, again.
Thanks,
Liang
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SN4PR0601MB3728D1F8ABC9C86972B6C53886590>