From owner-freebsd-net@freebsd.org Thu Sep 3 11:13:59 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62FBA9C9B8B for ; Thu, 3 Sep 2015 11:13:59 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 29EA3106A for ; Thu, 3 Sep 2015 11:13:58 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id A8B407E81E; Thu, 3 Sep 2015 21:13:48 +1000 (EST) Message-ID: <55E82B59.6000202@freebsd.org> Date: Thu, 03 Sep 2015 21:13:29 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: hiren panchasara , freebsd-net@freebsd.org Subject: Re: Value of congestion window (cwnd) when loss is detected References: <20150903005405.GN68814@strugglingcoder.info> In-Reply-To: <20150903005405.GN68814@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 11:13:59 -0000 On 09/03/15 10:54, hiren panchasara wrote: > I am failing to understand the reason behind this behavior. > > What should the congestion window (snd_cwnd) be set to when we hit loss? > It seems that we set it to 1 segment right now. > https://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?revision=286227&view=markup#l2531 > > I also see that in the simulations I did. Sender side pcap can be found > at: https://people.freebsd.org/~hiren/pcaps/single_packet_loss.pcap > > Trying to send 50kb of data from freebsd 10.2 server to freebsd client. > Initial cwnd is 10 so we blast out 10 packets but 1 packet gets dropped: > seq 2897:4345. We get 3 dupacks and we retransmit it. But as soon as we > detect this loss, we reduce cwnd to 1 segment. In fact, we could've used > data in SACK to see how much we could send on the n/w, imo. > > 3rd dup ack (which triggered the retransmit) looks like this: > IP 192.168.11.10.41674 > 192.168.10.10.http: Flags [.], ack 2897, win > 12579, options [nop,nop,TS val 4236220288 ecr 3905376863,nop,nop,sack 1 > {4345:10137}], length 0 > > And the retransmit: > IP 192.168.10.10.http > 192.168.11.10.41674: Flags [.], seq 2897:4345, > ack 172, win 12579, options [nop,nop,TS val 3905376894 ecr 4236220288], > length 1448 > > At this point in time, sender knows that it has sent 23169 bytes (last > packet server sent was seq 21721:23169) and received ack for 10137 > bytes minus a missing packet = 8689 bytes. i.e. 6 packets. So, there is > at least that much room on n/w at that point in time. We can go > conservative and halve that. i.e. 3 packets. That is still better than > going down to 1 packet. > > Is there something basic I am missing here? > Any insights would be helpful. You want to read up about window inflation during fast recovery in RFC 5681 followed by 3782, and then consult Stevens vol 2 to understand how variables are used for different purposes depending on connection state and which code path was taken (something I greatly dislike and would love to change one day). Cheers, Lawrence