From owner-freebsd-transport@freebsd.org Mon Feb 29 17:55:00 2016 Return-Path: Delivered-To: freebsd-transport@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 329E5AB88D7 for ; Mon, 29 Feb 2016 17:55:00 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 171C217B for ; Mon, 29 Feb 2016 17:55:00 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 16CECAB88CF; Mon, 29 Feb 2016 17:55:00 +0000 (UTC) Delivered-To: transport@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 F09C8AB88CE for ; Mon, 29 Feb 2016 17:54:59 +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 CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D3EE3177 for ; Mon, 29 Feb 2016 17:54:59 +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 ESMTPA id 3F68E1101EA; Mon, 29 Feb 2016 09:54:53 -0800 (PST) Date: Mon, 29 Feb 2016 09:54:53 -0800 From: hiren panchasara To: Yongmin Cho Cc: transport@freebsd.org Subject: Re: In TCP recovery state, problem of computing the pipe(amount of data in flight). Message-ID: <20160229175453.GA82027@strugglingcoder.info> References: <20160225112625.GA5680@yongmincho-All-Series> <20160227031604.GP31665@strugglingcoder.info> <20160229084045.GA21079@yongmincho-All-Series> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <20160229084045.GA21079@yongmincho-All-Series> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:55:00 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02/29/16 at 05:40P, Yongmin Cho wrote: > Thanks very much for the quick reply. >=20 > I'm sorry, I didn't make patch file. > First, I wanted to discuss my opinion is right. >=20 > Let me give you example, please check this. >=20 > <- ACK (cumack =3D 1, sack[3-4], sack[6-7], sack[9-10]) > * here segment/byte 2, 5, and 8 are missing. > <- ACK (cumack =3D 1, sack[12-13], sack[15-16], sack[18-19]) > * here segment/bytes 11, 14 and 17 are also reported missing. > <- ACK (cumack =3D 1, sack[18-19], sack[21-24], sack[27, 28]) > * here segment/bytes 20 and 25, 26 are missing. (triggered fast > retransmission) > <- ACK.....(cumack =3D 1, sack[21-24], sack[27, 28], sack[32, 33]) > <- ACK.....(cumack =3D 1, sack[34-35], sack[37, 40], sack[42, 44]) > <- ACK.....(cumack =3D 1, sack[34-35], sack[37, 40], sack[42, 45]) > <- ACKs.....(many duplication acks, and new sacked blocks) >=20 > In the fast recovery phase, the pipe is caculated like below, If the > net.inet.tcp.rfc6675_pipe is turned on. > pipe =3D snd_max - snd_una + sack_bytes_rexmit(1 MSS size) - > sacked_bytes(10 =3D 34-35, 37-40, 42-45 tcp_sack.c:390) > One segment is sended(sack_bytes_rexmit), when triggered fast > retransmission. > Because the snd_cwnd was set 1 mss size. (tcp_input.c:2609) > In the fast recovery phase, The sender can send data, > If this condition is right(awnd < tp->snd_ssthresh tcp_input.c:2568). > When in the network, It still has many in flight packets, > snd_max and snd_una will not be changed, and sack_bytes_rexmit is one MSS= =20 > size, and sacked_bytes is caculated by last ACK that has three SACK > blocks(34-35, 37-40, 42-45). > So, sometimes(In my test environment) the awnd(pipe) value can't go > down less than the snd_ssthresh, while receiving each ACKs > in fast recovery phase. > You know, If the awnd value can't go down less than the snd_ssthresh, > The sender can't send data that is included snd_holes. >=20 > So, I think, the sacked_bytes should be caculated by all of sacked > blocks that is greater than snd_una, like below. > pipe =3D snd_max - snd_una + sack_bytes_rexmit - sacked_bytes(3-4, 6-7, > 9-10, 12-13, 15-16, 18-19, 21-24, 27-28, ...). >=20 > But on current implementation, the sacked_bytes is caculated by three(or = four) > sacked blocks that is in last ACK, like below. > pipe =3D snd_max - snd_una + sack_bytes_rexmit - sacked_bytes(34-35, > 37-40, 42-45 -> sacked blocks of last ACK). >=20 > My opinion may not be right. Just I want to check implementation of > computing pipe. Your opinion seems correct to me. If you can create a patch based on this, that'd be great. As I cannot spend time on this until next week. Cheers, Hiren --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJW1IXpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lHI0H/0oCiaYy3zCPg2zoS8GwtEA0 +DacdGz0EfhBV0/XvEBf+0ffgFZGdikPjah4YDuxPQVgZEcT8/8yxaYKjr/NzjYQ MU2LW3QyixSnsjEcLEjseaxrPNRRM99cwFOuaWagq30XNHTP1fSeh4dq8KcGpNYN xWAH1dx2I95Sr+gCUqngzeuDqgEMiC9moN4Jmwdhu6xvk8bVFSgI9DnlGI3Hdf9u q+CXLVteLAO996YlnODVqx+DNISEws6OvaSspUiunX6X5+HaU3doOyEAHvYKHPJ/ bxXRt2t6QqJZohdyLXWkkGeoDhAu83W1llElvv6ZfZPC0KpRq9XrkEzpJAglYms= =7Qjt -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf--