From owner-freebsd-net@freebsd.org Thu Sep 3 00:54:07 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 09DA79C8B95 for ; Thu, 3 Sep 2015 00:54:07 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF1F21E5C for ; Thu, 3 Sep 2015 00:54:06 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id E2EEFCC514 for ; Wed, 2 Sep 2015 17:54:05 -0700 (PDT) Date: Wed, 2 Sep 2015 17:54:05 -0700 From: hiren panchasara To: freebsd-net@FreeBSD.org Subject: Value of congestion window (cwnd) when loss is detected Message-ID: <20150903005405.GN68814@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/UvyDgxjlFfP/4zZ" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) 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 00:54:07 -0000 --/UvyDgxjlFfP/4zZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. Cheers, Hiren --/UvyDgxjlFfP/4zZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJV55otXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l5YUH/06EVmLj18+NgLRZb8qmvbZZ RTSQm8jK37ha1CjXS4VJItXo3FImTEiJd/NMqnYUFlKrn9DymVZt03q+9H3E2hl4 ZtZ9mBkfvklwk0euaE0N5Ip7RVVS6cE5sYRCmNUe1IEomjBKpv8sOVZsHQ4+ajfX qS/3rbHvIl83VHq7jE7bZmXrjc75Ckd0Wm7gSNDAfoDOpDjMAXg6rjx6TH+KH/Eh uoesRscqm1XpQKJk8zx2xrF71as+n6TeXICneoCpdzNOWnctf8jA1F/cjNAHbScJ /mhg67GjtFAmPCV/g2F7clTL+3xSVaBscbEyY0EjFRnkbCpE1M0D5vQZ9qKh6Ko= =Trgd -----END PGP SIGNATURE----- --/UvyDgxjlFfP/4zZ--