Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 3 Mar 2003 22:48:06 +0800
From:      "Lu Guohan" <lguohan00@mails.tsinghua.edu.cn>
To:        <freebsd-net@freebsd.org>
Subject:   The inflated snd_cwnd doesn't get retracted after TCP recovered from multiple losses (4.5-RELEASE)
Message-ID:  <007501c2e193$e67589e0$668019d2@garfield>
next in thread | raw e-mail | index | archive | help 

hello,
    I am new to hear, and I am not sure if anyone post this problem before. And I am figuring out the way to post this problem by PR since the web interface is not avaiable right now.

Description:
    When TCP sender receives window update ack during loss recovery, the inflated tp->snd_cwnd doesn't get retracted after TCP recovered from multiple losses.
    For example, suppose the 20th,21th packets are lost. The sender then receives dup acks for the 20th packet and retranmits it. Later, received dup acks will make the sender to inflate its tp->snd_cwnd. Then the ack for the 21th packet arrives, and the sender retransmits it. If the th->th_win of this ack packet is less than the maximum value(likely), the sender will receive an window update ack very soon. This ack will make tp->t_dupacks = 0. Now, new acks that bring TCP out of loss recovery will keep tp->snd_cwnd as the inflated value, not the value required by RFC2581.
    Below is the trace, both the sender and the receiver run freebsd 4.5-RELEASE. I have many traces of this kind, it occurs frequently. This may even have security problem. I am not sure if this bug is fixed in later versions.

Traces:

packet 962921:964369(1448) and 965817:967265(1448) are lost.

002630 orson..2398 > roy..ftp-data: . ack 962921 win 30408 <nop,nop,timestamp 21192762 157667897> (DF)
000024 roy..ftp-data > orson..2398: . 978849:980297(1448) ack 1 win 33304 <nop,nop,timestamp 157667932 21192762> (DF)
000012 roy..ftp-data > orson..2398: . 980297:981745(1448) ack 1 win 33304 <nop,nop,timestamp 157667932 21192762> (DF)
002729 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192762 157667897> (DF)
002674 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192762 157667897> (DF)
000791 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192763 157667897> (DF)
001555 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192763 157667897> (DF)
000019 roy..ftp-data > orson..2398: . 962921:964369(1448) ack 1 win 33304 <nop,nop,timestamp 157667933 21192763> (DF)
~~~~~~~~~~~~~~~~retransmit first packet

003207 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192763 157667897> (DF)
002032 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192763 157667897> (DF)
000723 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192763 157667897> (DF)
000307 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192763 157667897> (DF)

------------------ window inflating
347611 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192796 157667897> (DF)
000019 roy..ftp-data > orson..2398: . 981745:983193(1448) ack 1 win 33304 <nop,nop,timestamp 157667968 21192796> (DF)
002675 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192796 157667897> (DF)
000017 roy..ftp-data > orson..2398: . 983193:984641(1448) ack 1 win 33304 <nop,nop,timestamp 157667968 21192796> (DF)
001468 orson..2398 > roy..ftp-data: . ack 962921 win 31856 <nop,nop,timestamp 21192796 157667897> (DF)
000018 roy..ftp-data > orson..2398: . 984641:986089(1448) ack 1 win 33304 <nop,nop,timestamp 157667968 21192796> (DF)
~~~~~~~~~~~~~~~~~~~~`


006248 orson..2398 > roy..ftp-data: . ack 965817 win 28960 <nop,nop,timestamp 21192797 157667933> (DF)
000019 roy..ftp-data > orson..2398: . 965817:967265(1448) ack 1 win 33304 <nop,nop,timestamp 157667969 21192797> (DF)
~~~~~~~~~~~~~~~~retransmit the second packet
000016 roy..ftp-data > orson..2398: . 986089:987537(1448) ack 1 win 33304 <nop,nop,timestamp 157667969 21192797> (DF)
000053 orson..2398 > roy..ftp-data: . ack 965817 win 31856 <nop,nop,timestamp 21192797 157667933> (DF)
~~~~~~~~~~~~~~~~~~~~`window update ack, the problem!

380330 orson..2398 > roy..ftp-data: . ack 965817 win 31856 <nop,nop,timestamp 21192832 157667933> (DF)
003723 orson..2398 > roy..ftp-data: . ack 965817 win 31856 <nop,nop,timestamp 21192833 157667933> (DF)
004701 orson..2398 > roy..ftp-data: . ack 965817 win 31856 <nop,nop,timestamp 21192833 157667933> (DF)
000020 roy..ftp-data > orson..2398: . 987537:988985(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192833> (DF)

---------------- TCP get of loss recovery, but inflated window doesn't retract
001956 orson..2398 > roy..ftp-data: . ack 986089 win 11584 <nop,nop,timestamp 21192834 157667969> (DF)
000023 roy..ftp-data > orson..2398: . 988985:990433(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000011 roy..ftp-data > orson..2398: . 990433:991881(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000013 roy..ftp-data > orson..2398: . 991881:993329(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000018 roy..ftp-data > orson..2398: . 993329:994777(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000015 orson..2398 > roy..ftp-data: . ack 986089 win 19776 <nop,nop,timestamp 21192834 157667969> (DF)
000019 roy..ftp-data > orson..2398: . 994777:996225(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000012 roy..ftp-data > orson..2398: . 996225:997673(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000016 roy..ftp-data > orson..2398: . 997673:999121(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000011 roy..ftp-data > orson..2398: . 999121:1000569(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000009 roy..ftp-data > orson..2398: . 1000569:1002017(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000009 roy..ftp-data > orson..2398: . 1002017:1003465(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
000028 roy..ftp-data > orson..2398: . 1003465:1004913(1448) ack 1 win 33304 <nop,nop,timestamp 157668008 21192834> (DF)
006475 orson..2398 > roy..ftp-data: . ack 986089 win 27968 <nop,nop,timestamp 21192834 157667969> (DF)
000027 roy..ftp-data > orson..2398: . 1004913:1006361(1448) ack 1 win 33304 <nop,nop,timestamp 157668009 21192834> (DF)
000012 roy..ftp-data > orson..2398: . 1006361:1007809(1448) ack 1 win 33304 <nop,nop,timestamp 157668009 21192834> (DF)
000011 roy..ftp-data > orson..2398: . 1007809:1009257(1448) ack 1 win 33304 <nop,nop,timestamp 157668009 21192834> (DF)


Code related to this issue:
In tcp_input.c


if (SEQ_LEQ(th->th_ack, tp->snd_una)) {
   if (tlen == 0 && tiwin == tp->snd_wnd) {
    .......
   } else
    tp->t_dupacks = 0;
   break;
  }

......

  /*
   * If t_dupacks != 0 here, it indicates that we are still
   * in NewReno fast recovery mode, so we leave the congestion
   * window alone.
   */
  if (tcp_do_newreno == 0 || tp->t_dupacks == 0)
   tp->snd_cwnd = min(cw + incr,TCP_MAXWIN<<tp->snd_scale);
  }


Guohan Lu

N'rzǧvf&j:+v "ryyb^nrazg

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007501c2e193$e67589e0$668019d2>