Date: Mon, 30 Jun 2003 10:26:37 +0800 From: "Lu Guohan" <lguohan00@mails.tsinghua.edu.cn> To: <freebsd-net@freebsd.org> Subject: [TCP Bug]The snd_cwnd is set to very very large size. Message-ID: <004001c33eaf$0858ebb0$668019d2@garfield>
next in thread | raw e-mail | index | archive | help
Hello,
Brief Description:
In the loss recovery phase, when a retransmit packet get lost, the sender will finally timeout. Then, after the sender receives the the ack packet that acked the retransmitted packet, in certain situations, the sender will regard the ack as an partial ack, where the 'snd_cwnd' will be set to a very large size, approxmately to the maximum value of a u_long integer. And total bytes equals to a receiver window size will be sent out in a burst.
Traces:
********************************
Sender Side:
06:01:33.424044 Orson.commplex-link > RoyF5_1.49161: . ack 511169 win 30408
06:01:33.424635 RoyF5_1.49161 > Orson.commplex-link: . 514065:515513(1448) ack 1 win 33304 [LOST!]
06:01:33.424718 RoyF5_1.49161 > Orson.commplex-link: . 515513:516961(1448) ack 1 win 33304
06:01:33.424826 RoyF5_1.49161 > Orson.commplex-link: . 516961:518409(1448) ack 1 win 33304
06:01:33.428710 Orson.commplex-link > RoyF5_1.49161: . ack 512617 win 31856
06:01:33.429281 RoyF5_1.49161 > Orson.commplex-link: . 518409:519857(1448) ack 1 win 33304
06:01:33.538542 Orson.commplex-link > RoyF5_1.49161: . ack 514065 win 31856
06:01:33.539177 RoyF5_1.49161 > Orson.commplex-link: . 519857:521305(1448) ack 1 win 33304 [LOST!]
06:01:33.819017 Orson.commplex-link > RoyF5_1.49161: . ack 514065 win 31856
06:01:33.819850 Orson.commplex-link > RoyF5_1.49161: . ack 514065 win 31856
06:01:33.822109 Orson.commplex-link > RoyF5_1.49161: . ack 514065 win 31856
06:01:33.822528 RoyF5_1.49161 > Orson.commplex-link: . 514065:515513(1448) ack 1 win 33304 DUP3[LOST!]
06:01:34.488055 RoyF5_1.49161 > Orson.commplex-link: . 514065:515513(1448) ack 1 win 33304 TO[LOST!]
06:01:35.636980 RoyF5_1.49161 > Orson.commplex-link: . 514065:515513(1448) ack 1 win 33304 TO
06:01:36.030416 Orson.commplex-link > RoyF5_1.49161: . ack 519857 win 26064
06:01:36.030452 Orson.commplex-link > RoyF5_1.49161: . ack 519857 win 31856
---------Burst of packets
06:01:36.031008 RoyF5_1.49161 > Orson.commplex-link: . 519857:521305(1448) ack 1 win 33304
06:01:36.031146 RoyF5_1.49161 > Orson.commplex-link: . 521305:522753(1448) ack 1 win 33304
06:01:36.031257 RoyF5_1.49161 > Orson.commplex-link: . 522753:524201(1448) ack 1 win 33304
06:01:36.031354 RoyF5_1.49161 > Orson.commplex-link: . 524201:525649(1448) ack 1 win 33304
06:01:36.031451 RoyF5_1.49161 > Orson.commplex-link: . 525649:527097(1448) ack 1 win 33304
06:01:36.031622 RoyF5_1.49161 > Orson.commplex-link: . 527097:528545(1448) ack 1 win 33304
06:01:36.031725 RoyF5_1.49161 > Orson.commplex-link: . 528545:529993(1448) ack 1 win 33304
06:01:36.031832 RoyF5_1.49161 > Orson.commplex-link: . 529993:531441(1448) ack 1 win 33304
06:01:36.032647 RoyF5_1.49161 > Orson.commplex-link: . 531441:532889(1448) ack 1 win 33304
06:01:36.032701 RoyF5_1.49161 > Orson.commplex-link: . 532889:534337(1448) ack 1 win 33304
06:01:36.032829 RoyF5_1.49161 > Orson.commplex-link: . 534337:535785(1448) ack 1 win 33304
06:01:36.032874 RoyF5_1.49161 > Orson.commplex-link: . 535785:537233(1448) ack 1 win 33304
06:01:36.032927 RoyF5_1.49161 > Orson.commplex-link: . 537233:538681(1448) ack 1 win 33304
06:01:36.032984 RoyF5_1.49161 > Orson.commplex-link: . 538681:540129(1448) ack 1 win 33304
06:01:36.033029 RoyF5_1.49161 > Orson.commplex-link: . 540129:541577(1448) ack 1 win 33304
06:01:36.033079 RoyF5_1.49161 > Orson.commplex-link: . 541577:543025(1448) ack 1 win 33304
06:01:36.033139 RoyF5_1.49161 > Orson.commplex-link: . 543025:544473(1448) ack 1 win 33304
06:01:36.033188 RoyF5_1.49161 > Orson.commplex-link: . 544473:545921(1448) ack 1 win 33304
06:01:36.033236 RoyF5_1.49161 > Orson.commplex-link: P 545921:547369(1448) ack 1 win 33304
06:01:36.034058 RoyF5_1.49161 > Orson.commplex-link: . 547369:548817(1448) ack 1 win 33304
06:01:36.034530 RoyF5_1.49161 > Orson.commplex-link: . 548817:550265(1448) ack 1 win 33304
06:01:36.034630 RoyF5_1.49161 > Orson.commplex-link: . 550265:551713(1448) ack 1 win 33304
****************************
Description with Code:
1. When a packet is lost and 3 dupacks received, TCP sets snd_recover = snd_max and retransmit the packet.(tcp_input.c)
2. The retransmited packet get lost, and timeout happens. Then, TCP sets snd_cwnd = t_maxseg.(tcp_timer.c)
3. When the ack of the retransmited packet arrives, TCP checks if the ack is a partial ack:
if (tcp_do_newreno) {
if (SEQ_LT(tp->snd_una, tp->snd_recover)) {
if (SEQ_LT(th->th_ack, tp->snd_recover)) {
If multiple data packets get lost in the previous round, the ack will be regarded as partial acks, and tcp_newreno_partial_ack() is called.
4. In tcp_newreno_partial_ack(), snd_cwnd will be reset.
tp->snd_cwnd -= (th->th_ack - tp->snd_una - tp->t_maxseg);
In this situation, snd_cwnd = t_maxseg, and (th_ack - snd_una - t_maxseg) will usually bigger than the t_maxseg, so snd_cwnd will be set to a very large value.
Suggested Solution:
Reset the snd_recover to th_ack in tcp_timer_rexmt(). Because if timeout happens, it means we are now switching to TCP slow start algorithm, and leave the newreno loss recovery phase. In freebsd, snd_recover is the main sign to indicate whether the TCP is in newreno LR phase or not. So, snd_recover should be reset in timeout().
Affected FreeBSD version:
newReno versions such as RELENG5_1, RELENG4, RELENG4_8, RELENG4_7 ...
************************************
Lu Guohan
Department of Electronic Engineering
Tsinghua University, P.R. China
lguohan00@mails.tsinghua.edu.cn
************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004001c33eaf$0858ebb0$668019d2>