Date: Thu, 3 Sep 2015 09:16:51 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: Lawrence Stewart <lstewart@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Value of congestion window (cwnd) when loss is detected Message-ID: <20150903161651.GQ68814@strugglingcoder.info> In-Reply-To: <55E82B59.6000202@freebsd.org> References: <20150903005405.GN68814@strugglingcoder.info> <55E82B59.6000202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--X35wERi4JU/f1kly Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/03/15 at 09:13P, Lawrence Stewart wrote: > On 09/03/15 10:54, hiren panchasara wrote: > > I am failing to understand the reason behind this behavior. > >=20 > > 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= =3D286227&view=3Dmarkup#l2531 > >=20 > > 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 > >=20 > > 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. > >=20 > > 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 > >=20 > > 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 > >=20 > > 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 =3D 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. > >=20 > > Is there something basic I am missing here? > > Any insights would be helpful. >=20 > 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). Thanks Lawrence for the pointers. From what I could see in the code (as I pointed above in original email) as soon as we get 3rd dup ack in tcp_do_segment() insdie 'else if (tp->t_dupacks =3D=3D tcprexmtthresh)' we check if we could do SACK with 'if (tp->t_flags & TF_SACK_PERMIT)' and we set 'tp->snd_cwnd =3D tp->t_maxseg;' before calling tcp_output(). And I've seen this behavior on many situations. So wanted to confirm if others are also seeing this. FWIW, I am using cubic cc. But as far as I can see, snd_cwnd setting for FreeBSD is outside of any cc algos' scope. i.e. We override whatever is being set. I'll do the necessary readings. Cheers, Hiren --X35wERi4JU/f1kly Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJV6HJyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lPaQH/3Hj5kIgPEfPESvpxfoXk3mT wXXKOW/fHoNBHO5tdkqH2pJGQKh5XZmU6dpzZp8gR+Sfg+wDu7lAbZwiwH2NzXQX KWcoOltJtaYnSUzA8afAlt98GBmUu7176zkbHdWa/+20mr6MA2VgRLCPDuBpqmSH yFGa3W+hRu+0MEXD1rC8sd+zlx6k0S9zykBEv1xaPL+bn/6HHjwcRwj2TqD1VREE Hu207WEQckBP82aolqy5hYsv5hc2cuH/iE/USt9yRm49LzhsqZVxVLB8faExkSIz +cEgVf4bMI+uQb87bZ3CjqSR6YE1woJHPJTtbFnkM6wKcCMolGamoZTal7Nbrfs= =Ghkx -----END PGP SIGNATURE----- --X35wERi4JU/f1kly--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150903161651.GQ68814>