From owner-freebsd-transport@freebsd.org Mon Feb 29 08:40:43 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 07FBFAB1259 for ; Mon, 29 Feb 2016 08:40:43 +0000 (UTC) (envelope-from yongmincho82@gmail.com) 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 DC3531964 for ; Mon, 29 Feb 2016 08:40:42 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D90FCAB1258; Mon, 29 Feb 2016 08:40:42 +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 D899DAB1256 for ; Mon, 29 Feb 2016 08:40:42 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB1AF1963 for ; Mon, 29 Feb 2016 08:40:42 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mail-pa0-x234.google.com with SMTP id bj10so19108885pad.2 for ; Mon, 29 Feb 2016 00:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=I2npGEq02uYzSN6YsRnXfVaAF0iJObgGqai9iCotYDw=; b=F6+N1NzSmuXqF99GAl5razIXlB/+7GCvW74baIQAeXEgeQTidUcBhylvxbpKt5jrnR ElCu7beHtdWjEQmxHCsvUkJKnybC3ddnkph9Tli8hbOL32lWfzj9mgplAe8pisVjyrjd OEx0RDPAmKMFrtxED2N8PQElCn7a5ND7TbVC5XvV685O84naPqbV5RY846ZXajtlJOGi iIknuQo9GxlTGNxlZ3CUgOn95s0m//+gTa1rjez/0LiplFBB767KI8NC/Nzu/bh62wl9 KZg5w2gI+fIUprCL6Zo2VN++K42Zrwa36jYh2Ip3wH8+2gH+KPqkTIK7FfDDevw5m/JY T4pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=I2npGEq02uYzSN6YsRnXfVaAF0iJObgGqai9iCotYDw=; b=dRS+GdbaQp+ICDP9yin9nWpouoSpIIze/kuiHNUu25p7mBzHn1Khz7ObwdHgknhWb5 L/vdUcs6L3OZXUrrBSz+SlH/pZxf6X3g7H4qPD8QQC1dN4llnRPLZVA0Sy/AcmDpvbN1 jkJI7lYG+WhHW5LHGg5tezeTN56JwCQfcdbgYBaamnk27FKM4pGVO38DBA6vToP/fAML 4XLo0CbOurc3ZdkjshGwEee0FiELTCh+fM0Lm/UstJKVaz8+YosH+kmV316xDFVja23m G8Y/8gR+7h+BcqJab9BTa0PfjjqQTHjORwUMTQbIOimxcnvjGsDUXWWXbEyIzjJe2EeX C2yg== X-Gm-Message-State: AD7BkJItsdBUzp73/Oqqtr1eso8Wa19O7TG0+V5wcXHUjorYDetKC894JQ5awik5yCY0tg== X-Received: by 10.66.190.168 with SMTP id gr8mr20767833pac.23.1456735241945; Mon, 29 Feb 2016 00:40:41 -0800 (PST) Received: from yongmincho-All-Series ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id q16sm36027843pfi.80.2016.02.29.00.40.40 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 29 Feb 2016 00:40:41 -0800 (PST) Date: Mon, 29 Feb 2016 17:40:47 +0900 From: Yongmin Cho To: hiren panchasara Cc: transport@freebsd.org Subject: Re: In TCP recovery state, problem of computing the pipe(amount of data in flight). Message-ID: <20160229084045.GA21079@yongmincho-All-Series> References: <20160225112625.GA5680@yongmincho-All-Series> <20160227031604.GP31665@strugglingcoder.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160227031604.GP31665@strugglingcoder.info> User-Agent: Mutt/1.5.21 (2010-09-15) 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 08:40:43 -0000 Thanks very much for the quick reply. I'm sorry, I didn't make patch file. First, I wanted to discuss my opinion is right. Let me give you example, please check this. <- ACK (cumack = 1, sack[3-4], sack[6-7], sack[9-10]) * here segment/byte 2, 5, and 8 are missing. <- ACK (cumack = 1, sack[12-13], sack[15-16], sack[18-19]) * here segment/bytes 11, 14 and 17 are also reported missing. <- ACK (cumack = 1, sack[18-19], sack[21-24], sack[27, 28]) * here segment/bytes 20 and 25, 26 are missing. (triggered fast retransmission) <- ACK.....(cumack = 1, sack[21-24], sack[27, 28], sack[32, 33]) <- ACK.....(cumack = 1, sack[34-35], sack[37, 40], sack[42, 44]) <- ACK.....(cumack = 1, sack[34-35], sack[37, 40], sack[42, 45]) <- ACKs.....(many duplication acks, and new sacked blocks) In the fast recovery phase, the pipe is caculated like below, If the net.inet.tcp.rfc6675_pipe is turned on. pipe = snd_max - snd_una + sack_bytes_rexmit(1 MSS size) - sacked_bytes(10 = 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 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. So, I think, the sacked_bytes should be caculated by all of sacked blocks that is greater than snd_una, like below. pipe = 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, ...). But on current implementation, the sacked_bytes is caculated by three(or four) sacked blocks that is in last ACK, like below. pipe = snd_max - snd_una + sack_bytes_rexmit - sacked_bytes(34-35, 37-40, 42-45 -> sacked blocks of last ACK). My opinion may not be right. Just I want to check implementation of computing pipe. Thank you. On Fri, Feb 26, 2016 at 07:16:04PM -0800, hiren panchasara wrote: > On 02/25/16 at 08:26P, Yongmin Cho wrote: > > Hi, all. > > > > I have a question about net.inet.tcp.rfc6675_pipe in sysctl. > > The bytes in flight was changed to be like below in r290122. > > pipe = snd_max - snd_una - sackhint.sacked_bytes + > > sackhint.sack_bytes_rexmit. > > I think, The implementation of sackhint.sack_bytes_rexmit is right. > > But, I don't think, sackhint.sacked_bytes is right way. > > The sackhint.sacked_bytes is computed by array of sack_blocks in > > tcp_sack_doack function. > > You know, tcp header can have four sacked blocks. > > (If tcp uses timestmap option, tcp header can have three sacked > > blocks.) > > Even if The receiver has sacked blocks greater than three or four, > > The receiver can send ack with three or four last sack blocks. > > So if the receiver has many sacked blocks, the sender only knows three > > sacked_bytes. > > the snd_holes tail queue in struct tcpcb has all of sack holes which > > is greater than snd_una. > > So, i think, sack_bytes_rexmit is correct. > > Because sack_bytes_rexmit is computed by snd_holes tail queue in > > struct tcpcb. > > but sackhint.sacked_bytes is too small. > > Because sackhint.sacked_bytes is just computed by ack with three or > > four last sacked blocks. > > So, the return value of tcp_compute_pipe() function is too big, while > > recovery phase. > > In recovery state, the sender can send data, > > if the return value of tcp_compute_pipe() should be less than > > snd_ssthresh. > > Sometimes it takes a long time to send data, if the sender knows many > > sack holes. > > Furthermore, Sometimes the sender can't send data, Because the return > > value of tcp_compute_pipe() function. > > And retransmission timeout is triggered. > > Your analysis is correct and we did think about this. Please look at > https://reviews.freebsd.org/D3971 's summary section. Main reason for > going with this approach was that it was at least on the conservative > side i.e. would send less data (and not more) and would not bloat the > network. > > BTW, have you run into this problem of this causing slower recovery? > > > > IMO, sackhint.sack_bytes should be computed using snd_holes tail > > queue. > > Because snd_holes has all of sack holes which is greater than snd_una, > > sackhint.sack_bytes can be computed using snd_holes. > > I thought snd_holes also gets populated by the info in SACKs and if for > some reason other end has more than 3 or 4 holes and can't send it, > snd_holes would also have incorrect info. I'd have to look at the code > again to see if its possible to do this more correctly with snd_holes. > Though, I do see the point of this approach would provide better > protection against transient problems where other end cannot send SACK > holes info for a couple times and resumes again. Again, I'd have to go > look at the code closely. > > It'd be even better if you have a patch for this. If not, no worries. > :-) > > Cheers, > Hiren 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-- From owner-freebsd-transport@freebsd.org Wed Mar 2 15:52:30 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 D31A2AC0C17 for ; Wed, 2 Mar 2016 15:52:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) 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 C0BBE1FD6 for ; Wed, 2 Mar 2016 15:52:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id BEC1AAC0C16; Wed, 2 Mar 2016 15:52:30 +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 BE5C6AC0C15 for ; Wed, 2 Mar 2016 15:52:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from smtp.hungerhost.com (smtp.hungerhost.com [216.38.51.7]) (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 A073E1FD1 for ; Wed, 2 Mar 2016 15:52:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mobile-166-171-186-005.mycingular.net ([166.171.186.5]:19909 helo=[192.168.64.1]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ab94e-0003CH-S3 for transport@freebsd.org; Wed, 02 Mar 2016 10:52:28 -0500 From: "George Neville-Neil" To: transport@freebsd.org Subject: Moving the hangout to every other week Date: Wed, 02 Mar 2016 10:52:28 -0500 Message-ID: <920D2DF3-276A-4432-A6D8-0A895F794F50@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Authenticated-Sender: vps.hungerhost.com: gnn@neville-neil.com X-Source: X-Source-Args: X-Source-Dir: 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: Wed, 02 Mar 2016 15:52:30 -0000 Howdy, After the hangout on the 3rd (tomorrow) we'll be moving the meeting to every other week, so the next will be on the 17th. Best, George From owner-freebsd-transport@freebsd.org Wed Mar 2 15:55:30 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 8E885AC0D29 for ; Wed, 2 Mar 2016 15:55:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) 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 7AB041189 for ; Wed, 2 Mar 2016 15:55:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id 76E34AC0D28; Wed, 2 Mar 2016 15:55:30 +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 76811AC0D27 for ; Wed, 2 Mar 2016 15:55:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from smtp.hungerhost.com (smtp.hungerhost.com [216.38.51.7]) (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 578931188 for ; Wed, 2 Mar 2016 15:55:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mobile-166-171-186-005.mycingular.net ([166.171.186.5]:58971 helo=[192.168.64.1]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ab97Z-0003sc-7P for transport@freebsd.org; Wed, 02 Mar 2016 10:55:29 -0500 From: "George Neville-Neil" To: transport@freebsd.org Subject: Re: Moving the hangout to every other week Date: Wed, 02 Mar 2016 10:55:28 -0500 Message-ID: <59D7BF6D-DE9F-41B6-A018-B650214ACC4A@neville-neil.com> In-Reply-To: <920D2DF3-276A-4432-A6D8-0A895F794F50@neville-neil.com> References: <920D2DF3-276A-4432-A6D8-0A895F794F50@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Authenticated-Sender: vps.hungerhost.com: gnn@neville-neil.com X-Source: X-Source-Args: X-Source-Dir: 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: Wed, 02 Mar 2016 15:55:30 -0000 Correction. Tomorrow's meeting is canceled. Meetings will then be every other week starting on the 10th. I will not be able to make the 10th so, please, someone take notes. Best, George On 2 Mar 2016, at 10:52, George Neville-Neil wrote: > Howdy, > > After the hangout on the 3rd (tomorrow) we'll be moving the meeting to > every other week, so the next will be on the 17th. > > Best, > George From owner-freebsd-transport@freebsd.org Wed Mar 2 16:24:12 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 B2EFAAC167D for ; Wed, 2 Mar 2016 16:24:12 +0000 (UTC) (envelope-from jtl@freebsd.org) 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 814921241 for ; Wed, 2 Mar 2016 16:24:12 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7DB8EAC167C; Wed, 2 Mar 2016 16:24:12 +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 7D48EAC167B for ; Wed, 2 Mar 2016 16:24:12 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0138.outbound.protection.outlook.com [157.56.110.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 207481240 for ; Wed, 2 Mar 2016 16:24:11 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from BY1PR0501CA0024.namprd05.prod.outlook.com (10.162.139.34) by BN3PR0501MB1603.namprd05.prod.outlook.com (10.161.217.20) with Microsoft SMTP Server (TLS) id 15.1.415.20; Wed, 2 Mar 2016 16:24:10 +0000 Received: from BL2FFO11FD024.protection.gbl (2a01:111:f400:7c09::164) by BY1PR0501CA0024.outlook.office365.com (2a01:111:e400:4821::34) with Microsoft SMTP Server (TLS) id 15.1.427.16 via Frontend Transport; Wed, 2 Mar 2016 16:24:09 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=freebsd.org; neville-neil.com; dkim=none (message not signed) header.d=none;neville-neil.com; dmarc=none action=none header.from=freebsd.org; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning freebsd.org discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.1.427.7 via Frontend Transport; Wed, 2 Mar 2016 16:24:08 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 2 Mar 2016 08:24:06 -0800 Received: from [172.29.36.179] (teresasun-sslvpn-nc.jnpr.net [172.29.36.179]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u22GO3D73370; Wed, 2 Mar 2016 08:24:04 -0800 (PST) (envelope-from jtl@freebsd.org) User-Agent: Microsoft-MacOutlook/14.6.1.160122 Date: Wed, 2 Mar 2016 11:24:01 -0500 Subject: Re: Moving the hangout to every other week From: "Jonathan T. Looney" Sender: Jonathan Looney To: George Neville-Neil , "transport@freebsd.org" Message-ID: Thread-Topic: Moving the hangout to every other week References: <920D2DF3-276A-4432-A6D8-0A895F794F50@neville-neil.com> <59D7BF6D-DE9F-41B6-A018-B650214ACC4A@neville-neil.com> In-Reply-To: <59D7BF6D-DE9F-41B6-A018-B650214ACC4A@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CPI:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(2980300002)(479174004)(377454003)(189002)(199003)(24454002)(586003)(86362001)(47776003)(69596002)(16796002)(76176999)(50986999)(83506001)(54356999)(19580395003)(87936001)(81156010)(19580405001)(2906002)(92566002)(46406003)(5001960100004)(6806005)(2950100001)(105596002)(36756003)(50466002)(23726003)(5001770100001)(2501003)(106466001)(230700001)(107886002)(1096002)(1220700001)(189998001)(77096005)(4001350100001)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1603; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:None; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD024; 1:2xgRQcDi8Cv1jxGijX8I/YsRHghaXcd1OGBgz8HTzcXWvzfOkb1I61zntbiFNFheIGWdcJMbbbYHbsduyBIYlo61nACvuT1e/qul/UnkvvubJcgCVQaLJsv3ldd7mSC9XrLg3KUKABwpCxJnOIavfEliAiz42opsUuDUxacN/4wV1iWSlGiLAWbYSdsQpWqTNhioPycxBY+53okQwZLxlaQ7DU9c4q9cS7BexK9bXB+FmRcxLwTZysW31iOnfZuGNN5TQsAFncSCLiJ69sfIkX2MGsLjIm+a//YuSokU9R/PlEuTt2YQ0oRyB5TRS3wUfJ0AStLscqNfRqX1o0+i0LIdmjtO1seeioWAi3C5D595PjkacW6jrK4lH60Zv/JY3TMGRJDjQjRYG8aixHLJ7PLvp0jdRc5veOBufpMQvW0= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1603; 2:Vy1ebxct0sCjOxYd4NAiUemSjYkzxBP1nlXW8HJHGdC9xGYesi/BDcHaNgjFMyP6rWnC1VmXRj4rKoy0yebNVTEsjW8G142LslA+rbppvw7dgH6LfXW5/we5bMjX9lApumqIMAdq6rHlKOB/Dk2o2A==; 3:e7INi8fGbQm02RYA7r5Xhb4iOBUKQVm1u/dIfFCYJ3R3gaxjwBxUEDFZAHsFJBOnlhkVU6vM+ipSvbLaxLm5PoFiYyZNYMGVK1Z+6zrgVez/ha4dV+b85YTn7t0eBsk9o2bcNuDJM5rnP9zw0AVJKMv4LLll+CM8KiKdk8W+vH0=; 25:+o1EzvV7Aq2gPI8epVlqbusdVZARwFKYJLpqxrLT7bh26f+9UJe3EDzZWBtuPlbgRorbMG4udI/OTVu+wpIjEh1PRk4BSJnTvZFigb8w8Wau+3ZgOp3UsXaRudbzKq5T9pQ3Pt9egNAcIq4lHF9v2opSufyoBfpx2clnBOmRZEPVn+kUD8+e28ayOmcEHC3wg6rfJAkpQh6ptrKzpPktdOJSL1T4AXqsjQ6uDx5dNbID7l5tnt7APYBdupXmqevjTWIRFKXKQh90U8TwjmReAYVRqgjalQtWtZgDNx7BKtxuFfc37vt+zszuO13q8F1SUzwP1jPKdITOmYeZYsPvrA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1603; X-MS-Office365-Filtering-Correlation-Id: fc9b1f80-1009-4d7c-e26f-08d342b714d8 X-JNPR-Received-From: outside X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1603; 20:fwgHjt+9i58j7Ww7PWOcPVB9NOoDdlO6MIFiQrSBd5omAs/nHNS++jZb3fMPDoNKONL6NcZzfHP8RhbO+HotlBjbBjEHCjF3nvnDkgJSjpnFCcAJC2I0J4hf1cN+lTFa1fXoIaiNHx4p8VNaQMzos8DRCeZSF7CqvqDW/bIZYggN9KlzRMNTyZUaeRPZdOw7uElCiA8amUE9csm5SsyS5pts9o7qwSi/j2M5J+M8JD1BKhPPVsN1M7CMHlQHVRi4kpL2v/PvmJcWyFqzDd204jZObjkDHsKgLU0cv+UKsOHZScGgGcPP8KKP8n9TSCGKK/v2QQxAL1pKi86k2UKSm+7DVhBjzA01/5f0H8Z97A3vZfwU1KyOre5JHWJJBIkTQDZ8+pJdxDI+zLrl/C2GJwkHUxIgjXBrAPCAivn+5xwy1Qvc95XckqRtLBjSosLsddlFbempwuv03qbbmTZwQGXQwndwLHnmf27d07MXAkypBsgVVhHe6zEjvGiZeZm1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13015025)(13017025)(13023025)(13024025)(5005006)(8121501046)(13018025)(3002001)(10201501046); SRVR:BN3PR0501MB1603; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1603; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1603; 4:OKEtpZf/TK4j4tR6HE3MTpB5vLAHsG3qUCxfVDhtkFm8UU8lA/Sb18qKJs4iHRe2P7/0dQ2uDZAX6kzdv23Rec/Hz5yvwyinI1CNPfLUX2aMje0VPcsW3hH6+Lm7LsC6vMQTnrevl8aootfRsdLt1djDZ07e9RyRh+w0s8ePDbcvkMe91VA8VAIFnGNB5EX9AoxapwrbqOoqUvzQAHrOiaqqpmKAvqC2C1hn+BVg0zDdxFzuTcGGQH94cAt4LeI3700kM1KRVXiXsTg5S3pzeNZwIHVsXROvQLsel5BIHjhppW26ZXS+8ULC4NxgyKO/fDkvzjaCc6lZfcrRXThw6akzDuDZ6T4xe0D0A0oEsKzTaMQGWxo3tCxqfrR1PdKwPogQqrGKUyVFzrzr6xL4Uyij/LYuSyZZ163KscNGn/mcuzpTvr2hqutBPaDFVQ9UoOSpuA15mWrTe+YfhIQrsA== X-Forefront-PRVS: 086943A159 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1603; 23:7b/f9YewZbn2XWE+ogCdHvb/GmqaFZUUybcmV5q?= =?us-ascii?Q?0blk70AWZNntZ1qG4kkzKdfBnyKbbh208g1+OhhK30s5AbJgTmBswAgVBjLn?= =?us-ascii?Q?nHpp28nfvIGdeN1FvbRmHq5ZyPWEfWMCBUeZaPXnvOr1nASWM6kzflhJo60Y?= =?us-ascii?Q?BCFXryjlzblOMki2coMWiSAMWl9yxOdpEurHbylqgWE0f9PHzUGbX7sg6kSU?= =?us-ascii?Q?M5jhEPY2sbwZQrHePmTcCZtufJmwAlJ/+1APFBiMyau24mpyeZyaapkgvCti?= =?us-ascii?Q?N5A7nhk9AugkhGB4up4zOXMWZvYaEc6zzCG6720iXpnsxV80vt5MdgGe4PQd?= =?us-ascii?Q?81O2S/sK8R3yGiVOUd9NK9m1m0dqC3aAxodbLcA8QTRIKEaBWKrT4I4p6Z1A?= =?us-ascii?Q?qD0xQ/rHEuRkOT5CT5x4B10XENTPN7QB+hWbDMMRGkvF6hRitG9eKNcn128q?= =?us-ascii?Q?D7tLAQjJUYZ7ngyVRP+UzBSMURo103FF1LQNF8sD28lNEgnbmIsLscrlK2b4?= =?us-ascii?Q?1E54I1THBQviVsbyjT4HNQCPQqnHLUivCHqUQb9t+Xm7xiZcIJGC0ZCmqPVb?= =?us-ascii?Q?UcgeBCChnZT8R+YKvuPYkH1DRxbZOCXNtAdNq+bbgJJQkuvmkUDajELzlFe5?= =?us-ascii?Q?RaFRLNCBFLha8e0o7vlxSKMR08RYh6l59KZH0UooWCLqROtDXOyum2W1HZLb?= =?us-ascii?Q?6RbD502n2TSHCgRv8zZTg0Iegb2L1Dc/85KeGLXs795r9UFGWjFsec45ueJI?= =?us-ascii?Q?EZy8v9aWZmMco3e6G2cRRGX0ldGfM1R+eNeduAOjWfe2HtZO+ZPn0d6igQUK?= =?us-ascii?Q?QVzdM88FceFMewWrmEiAbuWuZusQ8zNeHVrAG2txsBzXBl/dA+2oe/KYpDG6?= =?us-ascii?Q?28L/L91DLO0ZzqXsu9Lp5NyIx6DQB1L00aTSQwkIo4nwszqdo4z0ATCT7XRe?= =?us-ascii?Q?Nxy/z9vO2mtdPu8AhNdyaDyNi1Jy/CQicFvOmjVcpPbt0HrMsuSLyRdlE/dD?= =?us-ascii?Q?B0ZZrmWhfd+virFwU7jFfhSO5/0HDEsDsxG2dXJQtAgXAY98koHSJ5KPa+ze?= =?us-ascii?Q?wLh1Jt3wXycoZ+Cf6sVlaHPcCqmYlPJWNrSYzuCekdBaHt9DDkMx8x4GawjU?= =?us-ascii?Q?AJ3tYrOTHQVbTeYS+k8mGy9ri60RKo8aHAKDT+HxfOUPOfVgu440PZjZv3ae?= =?us-ascii?Q?oyFcjJ1y35chUY84=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1603; 5:3KwgDzCY2BojsjWWrFHRUjV+Nv4lBXMFAfrZpVpC5xm+fibPB0fvvrLfyQDLAif/vd75+UGrwD+7wG1zmVSF21F17JGaPAm8hqo3yD+bitnrS4VEWgko3EsO0vbm0f4/lXmpJS9/nvzXRXO0ct/x+A==; 24:dEZF+J+lnMrxDMvFvgQodQHXQ9KPTqgUEB05fnC3IujxYfv1UqUaSchYoCc2SpKmuRkaHz4nJNL07XhCD06Z0tQyeSXm6aS/3MJXaw4gHWs= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2016 16:24:08.1990 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1603 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: Wed, 02 Mar 2016 16:24:12 -0000 On 3/2/16, 10:55 AM, "owner-freebsd-transport@freebsd.org on behalf of George Neville-Neil" wrote: >Correction. Tomorrow's meeting is canceled. Meetings will then be >every other week starting on the 10th. I will not be able to make the >10th so, please, someone take notes. I can take notes. Jonathan From owner-freebsd-transport@freebsd.org Thu Mar 3 01:15:03 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 636E1AC16CC for ; Thu, 3 Mar 2016 01:15:03 +0000 (UTC) (envelope-from yongmincho82@gmail.com) 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 4221B14DA for ; Thu, 3 Mar 2016 01:15:03 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3FD9CAC16CB; Thu, 3 Mar 2016 01:15:03 +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 3F6EDAC16CA for ; Thu, 3 Mar 2016 01:15:03 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E1DB14D9 for ; Thu, 3 Mar 2016 01:15:03 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mail-pf0-x234.google.com with SMTP id 124so4335719pfg.0 for ; Wed, 02 Mar 2016 17:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fhl72KwdCbFyo9EPzMK8wyuwpEh9jhLOYUdXYJJOUlU=; b=ok2vx+G32h0b9/PenTB+rN5WNkwoO9Z5qUYNdkxWE/D5Vn9/i5nJ5EftTcW0Y/vch9 NkBHG++GXyo+bY5jlKwYExeGFOBOcO7ikhXqUjr/9hpbDwi31Aq20T2ENoCRveVp87WP vcMfZy4mmvjPQTr/s6oZx220PNdYH01Pis5IvPwAMi9rtalxQFQ92lIZGkIirlx5bu10 n5niqz042IGHf5OJojOE6WbAymLTRp9gih5Yvp3tLnNLMlhs1AqXJRudlFZWfgdhzItq vzyzdRvFjwtttX2dZWHcTYztVzd9kXFtQZNvzPzVm4THpQFkAX/t/N/+H1Sy+nVqRaUn 5tJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fhl72KwdCbFyo9EPzMK8wyuwpEh9jhLOYUdXYJJOUlU=; b=UD0etUT1oW2VhBTPQX9C9fN2/ZaMRNELYZqtr/CbyDbDtF9Qufo1UtLpo/qp8clbwy AFiM7JQ43qSj6oVOHWt1V1kU147gHIcHICzpYqg7W4I85gI+LGdbPK6+vAm44R3ptb0F HMeaO0BCCLJQwnoQ3tcn6RrGxtiIbPMWrh7mjVzdvlx+gsf44DO1b/49XoyKA2r0RQfU To2dTY/E4HO7lRiGLrfq9edKy+BTiH8vIKBK7rCeQp3825SCAAVSekrM7rQs+8CELCB4 YcinE6iifhCkaxjimXc1e53Tdm6M25A5M+WHVHX+D6aIG6haefLo5+7MNi8IMVDCd0F8 HeQQ== X-Gm-Message-State: AD7BkJIVqVAKaA78tEEyn49dQO3ODEKzP95Gj9muB6o5lj6RbkkZ4DuyBPYkTpMGwJwSmQ== X-Received: by 10.98.34.212 with SMTP id p81mr42575546pfj.23.1456967702484; Wed, 02 Mar 2016 17:15:02 -0800 (PST) Received: from yongmincho-All-Series ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id ux2sm55791429pac.46.2016.03.02.17.15.01 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 02 Mar 2016 17:15:02 -0800 (PST) Date: Thu, 3 Mar 2016 10:15:08 +0900 From: Yongmin Cho To: hiren panchasara Cc: transport@freebsd.org Subject: Re: In TCP recovery state, problem of computing the pipe(amount of data in flight). Message-ID: <20160303011507.GB32665@yongmincho-All-Series> References: <20160225112625.GA5680@yongmincho-All-Series> <20160227031604.GP31665@strugglingcoder.info> <20160229084045.GA21079@yongmincho-All-Series> <20160229175453.GA82027@strugglingcoder.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160229175453.GA82027@strugglingcoder.info> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 03 Mar 2016 01:15:03 -0000 Thanks for the reply. I will try to create a patch based on this. Thanks. 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. > > > > I'm sorry, I didn't make patch file. > > First, I wanted to discuss my opinion is right. > > > > Let me give you example, please check this. > > > > <- ACK (cumack = 1, sack[3-4], sack[6-7], sack[9-10]) > > * here segment/byte 2, 5, and 8 are missing. > > <- ACK (cumack = 1, sack[12-13], sack[15-16], sack[18-19]) > > * here segment/bytes 11, 14 and 17 are also reported missing. > > <- ACK (cumack = 1, sack[18-19], sack[21-24], sack[27, 28]) > > * here segment/bytes 20 and 25, 26 are missing. (triggered fast > > retransmission) > > <- ACK.....(cumack = 1, sack[21-24], sack[27, 28], sack[32, 33]) > > <- ACK.....(cumack = 1, sack[34-35], sack[37, 40], sack[42, 44]) > > <- ACK.....(cumack = 1, sack[34-35], sack[37, 40], sack[42, 45]) > > <- ACKs.....(many duplication acks, and new sacked blocks) > > > > In the fast recovery phase, the pipe is caculated like below, If the > > net.inet.tcp.rfc6675_pipe is turned on. > > pipe = snd_max - snd_una + sack_bytes_rexmit(1 MSS size) - > > sacked_bytes(10 = 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 > > 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. > > > > So, I think, the sacked_bytes should be caculated by all of sacked > > blocks that is greater than snd_una, like below. > > pipe = 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, ...). > > > > But on current implementation, the sacked_bytes is caculated by three(or four) > > sacked blocks that is in last ACK, like below. > > pipe = snd_max - snd_una + sack_bytes_rexmit - sacked_bytes(34-35, > > 37-40, 42-45 -> sacked blocks of last ACK). > > > > 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