Date: Mon, 7 Mar 2016 18:30:42 -0800 From: hiren panchasara <hiren@strugglingcoder.info> To: Yongmin Cho <yongmincho82@gmail.com> Cc: transport@freebsd.org Subject: Re: In TCP recovery state, problem of computing the pipe(amount of data in flight). Message-ID: <20160308023042.GB49961@strugglingcoder.info> In-Reply-To: <20160308012930.GA24199@yongmincho-All-Series> References: <20160225112625.GA5680@yongmincho-All-Series> <20160227031604.GP31665@strugglingcoder.info> <20160229084045.GA21079@yongmincho-All-Series> <20160229175453.GA82027@strugglingcoder.info> <20160308012930.GA24199@yongmincho-All-Series>
next in thread | previous in thread | raw e-mail | index | archive | help
--oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/08/16 at 10:29P, Yongmin Cho wrote: > On Mon, Feb 29, 2016 at 09:54:53AM -0800, hiren panchasara wrote: > > 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. > >=20 > > 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. > >=20 > > Cheers, > > Hiren >=20 > I've created a patch based on this issue. >=20 > You know, The sack_blocks array in tcp_sack_doack function(tcp_sack.c) > have only 3 or 4 sacked blocks. > But We need to know all the data that has been sacked. > The snd_holes queue(in tcp_cb structure) is updated every time we get > an ACK with sack blocks. > So, the snd_holes queue know all of hole information. > And, We can get the sacked_bytes from the snd_holes. > So, I calculated the sacked_bytes every time when updating the > snd_holes. > I've tested this patch in my test environment, And I think, this > implementation is working well. >=20 > Please check this patch. any feedback will be welcome. Looks good on the first glance. I'll test this and update you. Great work! Cheers, Hiren --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJW3jlPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lFNUH/j64hQLPDx+csRxjagDLQBjU IKw8v2tcszNkDXETpGXKM3rvj0RXJi+OyqCN/WHXxdn4ot/3aZZ6okW75mgqxI8f +VnEo91qmTCsNIjO5M+GJR3sjRiJrNsYKVPE+EiAHk5mCFVNKKqWx0RWFy9q1oP4 +c5/bjUia6CZ60Z8yX3Kt+AZWfaVD7kmS0IqFvfro9IWAkmKm/D13qU0ptCnYWSA H17IUjTmMbwDiyEux50DlckHuGwagJ6UPwREl153PbIJ9xgteJEOJdAhxxjj9BHe 4J33Pp+jyVv9OdqLqyZGIvjAdC9prKVqTQpZcAbo28m9ttDbkRrVSTo426U0xG8= =32gC -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160308023042.GB49961>