From owner-freebsd-transport@freebsd.org Tue Mar 8 01:29:24 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 ADC72AC7E4D for ; Tue, 8 Mar 2016 01:29:24 +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 8B8BE614 for ; Tue, 8 Mar 2016 01:29:24 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8A57AAC7E4C; Tue, 8 Mar 2016 01:29:24 +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 71B49AC7E4B for ; Tue, 8 Mar 2016 01:29:24 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 4B692613 for ; Tue, 8 Mar 2016 01:29:24 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mail-pf0-x233.google.com with SMTP id x188so771396pfb.2 for ; Mon, 07 Mar 2016 17:29:24 -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=qdAOxx6HwVesR4mdhSb+AoW/7WKQQY80LwIjLmC0GtY=; b=o5wvKHpVY+zF31ccMSno5h3cyVydgAiWqmu0UI+gH0OwqapaDT9XZNagvoB2BxFc17 pPWFtJe9IayyfIJclYjbCfgf4K6YHBB0HqmtvBM94DnbEuOjvmD93TQ2dNt9PPFkQT4Y 04ygYwDXzoFJStpg/6WW4ie/O1B8iHpZ4/y9lN/q5MeMsyMmmgAMdK6YXdpIEgOzldKN uUtLquCaRCJ80RJzs2pc9u+ThVEZYeZsveFhEU2qz7lS7Da3VF/82F9Ok5e63XI8VOHW VZfcnS3bPTzLK2QrFq3s0JcSzd/ACP4G9cQrp8/JtFhqBwkO9htsQesP3fglPVGWzTGy Ob3g== 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=qdAOxx6HwVesR4mdhSb+AoW/7WKQQY80LwIjLmC0GtY=; b=O1p34AwFs1pHV6KOFi20U5wtaVWKF2I7YMy8anZIXAz0ThgRuOGSjhvz7jCjZbL1bV qyQDo05dv+cPYsfyziGdMM5yS1gyRKb0tF2HO/4NLtZqhrKaf3kfY8JmfHz1YXJx2cWa 76bBEd5IOVEa95K7v10LRakQsWi/2ehv1wxs4QKi1fB8qzJBc0nzqW6jtZlxN0l6EazW TnwyGO6/4U0ifHlKW/sUIzmtQK+KOgjl0jkKXCJ7hpw7vqk2B9NnYL2qRvEP5eZW6hEc sdtQsK1MbfxaVl7UydOAjIF4/2RuJCodePuxQFg4Mvtpu68Fa+Bnq9BKGkNKc/ivFQpE vLjA== X-Gm-Message-State: AD7BkJKv5dJQY/wQi0f0+2Rwyfiqd3Oco6LJEWH7lO4e5UjmRZIH+Xw56NXKipnMMg0DRw== X-Received: by 10.98.72.193 with SMTP id q62mr38178701pfi.117.1457400563734; Mon, 07 Mar 2016 17:29:23 -0800 (PST) Received: from yongmincho-All-Series ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id wq3sm315439pac.44.2016.03.07.17.29.21 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 07 Mar 2016 17:29:22 -0800 (PST) Date: Tue, 8 Mar 2016 10:29:32 +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: <20160308012930.GA24199@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: multipart/mixed; boundary="oyUTqETQ0mS9luUI" 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.21 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: Tue, 08 Mar 2016 01:29:24 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 I've created a patch based on this issue. 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. Please check this patch. any feedback will be welcome. Thanks. --oyUTqETQ0mS9luUI Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="tcp_sack.diff" Index: sys/netinet/tcp_sack.c =================================================================== --- sys/netinet/tcp_sack.c (revision 296480) +++ sys/netinet/tcp_sack.c (working copy) @@ -355,12 +355,13 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to { struct sackhole *cur, *temp; struct sackblk sack, sack_blocks[TCP_MAX_SACK + 1], *sblkp; - int i, j, num_sack_blks, sack_changed; + int i, j, num_sack_blks, sack_changed, sacked_bytes; INP_WLOCK_ASSERT(tp->t_inpcb); num_sack_blks = 0; sack_changed = 0; + sacked_bytes = 0; /* * If SND.UNA will be advanced by SEG.ACK, and if SACK holes exist, * treat [SND.UNA, SEG.ACK) as if it is a SACK block. @@ -374,7 +375,6 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to * received new blocks from the other side. */ if (to->to_flags & TOF_SACK) { - tp->sackhint.sacked_bytes = 0; /* reset */ for (i = 0; i < to->to_nsacks; i++) { bcopy((to->to_sacks + i * TCPOLEN_SACK), &sack, sizeof(sack)); @@ -387,8 +387,6 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to SEQ_GT(sack.end, tp->snd_una) && SEQ_LEQ(sack.end, tp->snd_max)) { sack_blocks[num_sack_blks++] = sack; - tp->sackhint.sacked_bytes += - (sack.end-sack.start); } } } @@ -446,6 +444,7 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to temp = tcp_sackhole_insert(tp, tp->snd_fack,sblkp->start,NULL); if (temp != NULL) { tp->snd_fack = sblkp->end; + sacked_bytes += (sblkp->end - sblkp->start); /* Go to the previous sack block. */ sblkp--; sack_changed = 1; @@ -462,11 +461,14 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to SEQ_LT(tp->snd_fack, sblkp->start)) sblkp--; if (sblkp >= sack_blocks && - SEQ_LT(tp->snd_fack, sblkp->end)) + SEQ_LT(tp->snd_fack, sblkp->end)) { + sacked_bytes += (sblkp->end - tp->snd_fack); tp->snd_fack = sblkp->end; + } } } else if (SEQ_LT(tp->snd_fack, sblkp->end)) { /* fack is advanced. */ + sacked_bytes += (sblkp->end - tp->snd_fack); tp->snd_fack = sblkp->end; sack_changed = 1; } @@ -503,6 +505,10 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to /* Data acks at least the beginning of hole. */ if (SEQ_GEQ(sblkp->end, cur->end)) { /* Acks entire hole, so delete hole. */ + if (SEQ_GT(cur->start, th_ack)) + sacked_bytes += (cur->end - cur->start); + else + sacked_bytes -= (sblkp->end - cur->end); temp = cur; cur = TAILQ_PREV(cur, sackhole_head, scblink); tcp_sackhole_remove(tp, temp); @@ -514,6 +520,8 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to continue; } else { /* Move start of hole forward. */ + if (SEQ_GT(sblkp->start, th_ack)) + sacked_bytes += (sblkp->end - cur->start); cur->start = sblkp->end; cur->rxmit = SEQ_MAX(cur->rxmit, cur->start); } @@ -521,6 +529,7 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to /* Data acks at least the end of hole. */ if (SEQ_GEQ(sblkp->end, cur->end)) { /* Move end of hole backward. */ + sacked_bytes += (cur->end - sblkp->start); cur->end = sblkp->start; cur->rxmit = SEQ_MIN(cur->rxmit, cur->end); } else { @@ -528,6 +537,7 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to * ACKs some data in middle of a hole; need * to split current hole */ + sacked_bytes += (sblkp->end - sblkp->start); temp = tcp_sackhole_insert(tp, sblkp->end, cur->end, cur); if (temp != NULL) { @@ -554,6 +564,7 @@ tcp_sack_doack(struct tcpcb *tp, struct tcpopt *to else sblkp--; } + tp->sackhint.sacked_bytes += sacked_bytes; return (sack_changed); } --oyUTqETQ0mS9luUI-- From owner-freebsd-transport@freebsd.org Wed Mar 9 01:57:52 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 06387AC8344 for ; Wed, 9 Mar 2016 01:57:52 +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 E7674CF1 for ; Wed, 9 Mar 2016 01:57:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id E2806AC8343; Wed, 9 Mar 2016 01:57:51 +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 E20FBAC8342 for ; Wed, 9 Mar 2016 01:57:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by mx1.freebsd.org (Postfix) with ESMTP id D3E2BCEF for ; Wed, 9 Mar 2016 01:57:51 +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 AC0DA17482; Mon, 7 Mar 2016 18:30:42 -0800 (PST) Date: Mon, 7 Mar 2016 18:30:42 -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: <20160308023042.GB49961@strugglingcoder.info> References: <20160225112625.GA5680@yongmincho-All-Series> <20160227031604.GP31665@strugglingcoder.info> <20160229084045.GA21079@yongmincho-All-Series> <20160229175453.GA82027@strugglingcoder.info> <20160308012930.GA24199@yongmincho-All-Series> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: <20160308012930.GA24199@yongmincho-All-Series> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 01:57:52 -0000 --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-- From owner-freebsd-transport@freebsd.org Thu Mar 10 17:36:37 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 964E7ACBB81 for ; Thu, 10 Mar 2016 17:36:37 +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 49FF45DF for ; Thu, 10 Mar 2016 17:36:37 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 45D50ACBB7F; Thu, 10 Mar 2016 17:36:37 +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 455CAACBB7E for ; Thu, 10 Mar 2016 17:36:37 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0102.outbound.protection.outlook.com [157.56.111.102]) (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 A5B0D418 for ; Thu, 10 Mar 2016 17:36:36 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from BL2PR05CA0048.namprd05.prod.outlook.com (10.255.226.48) by CY1PR0501MB1803.namprd05.prod.outlook.com (10.163.141.141) with Microsoft SMTP Server (TLS) id 15.1.427.16; Thu, 10 Mar 2016 17:03:12 +0000 Received: from BY2FFO11FD030.protection.gbl (2a01:111:f400:7c0c::120) by BL2PR05CA0048.outlook.office365.com (2a01:111:e400:c04::48) with Microsoft SMTP Server (TLS) id 15.1.427.16 via Frontend Transport; Thu, 10 Mar 2016 17:03:11 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=freebsd.org; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; 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 BY2FFO11FD030.mail.protection.outlook.com (10.1.14.211) with Microsoft SMTP Server (TLS) id 15.1.434.11 via Frontend Transport; Thu, 10 Mar 2016 17:03:11 +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; Thu, 10 Mar 2016 09:03:10 -0800 Received: from [172.29.37.211] ([172.29.37.211]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u2AH2kD66295 for ; Thu, 10 Mar 2016 09:03:06 -0800 (PST) (envelope-from jtl@freebsd.org) User-Agent: Microsoft-MacOutlook/14.6.1.160122 Date: Thu, 10 Mar 2016 12:02:44 -0500 Subject: Re: Moving the hangout to every other week From: "Jonathan T. Looney" Sender: Jonathan Looney To: "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: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(377454003)(479174004)(199003)(83506001)(1220700001)(1096002)(15975445007)(81166005)(47776003)(1730700002)(19580405001)(86362001)(19580395003)(4001350100001)(23726003)(77096005)(50986999)(50466002)(450100001)(11100500001)(54356999)(46406003)(189998001)(6806005)(2950100001)(2906002)(2501003)(230700001)(2351001)(106466001)(87936001)(76176999)(92566002)(36756003)(16796002)(586003)(110136002)(107886002)(5640700001)(105596002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1803; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD030; 1:QbDNtSBuCcP0lZoR+HiLozj1nuWMYxmZOxAI47AcV9QSEQ//a82i73HekFwmz2jxgFQ24LZkOMWGO68iUtsZ28W0H+Yws3QUHDiAjewCpaq9U7iYEuVTdrU31vqUkgcdEC2nQGB+Qa25m0mtMSkBb65zZ+x/kEhFeYA8k9Ltu8dgO7amzqkTzdIHxi/eadYvS+miYsn5UH9YGmyC4IEhx0kIhlJN9rN3Z4cE3jhxthtUTAgM7okrgeOpoyQIByJhFrtTRG461nP7Fm4rowPukEtvQJ6J0GGg+7XUeV3eY1vTAkwDlr1EUYbKkBuhgRnFCqLMxm6U/gXDb+wDaxKA7sjT9Q0+eEj2UTyrjko5lxUhBp75JPuMgBOMIlQDOUNyygcxi6HFaMel2RkZNV9V+6guRP3hU0WcFSSz/Q3loXI9YAAaCKtz4hrGCVvlNjChEfIZMMfLJGYx9o7qwTq8Yw== X-MS-Office365-Filtering-Correlation-Id: e7e9b666-4a83-4dc9-9d27-08d34905dc8a X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1803; 2:+GxHArbGERfnY2+2tlmxIcy5jD01aPf3eUT9pbg2RGL3AK4p5fbgl+yTsTf/C6A+mb0in1nu5+NkkH7qQnCco/VQz2m5zutSvPyRpNTGOVW730WNqb11fegygAswSlEn5KTXYimdRW7Rn8VoRgeRYW0ZwugwhPnw2Pu0SOqO/VMJTm346lkwAXtov2EmGRs0; 3:foT7W9Bs1YFpZ5F+9neZZF7SnWqWGDvg440lEXXbzUjw+dZbjb6FXWOLd3/rsMdGQ794BpR2HTFpf3dXT2BUjfsUXkZmM/5FTXN+bf6+iYK14yC7dPh77kAkv0H5INGZKvotRmswEpfB6BAgJjmeZ5MkpSB5wADNAG/O8/oeZn1M1ood9HvS0RAc32wDadZ+n4mIhl6Irvh3vnsgoKpGuhBEmwWnm7nXyZebFQckja8=; 25:pnYmI3IW/UlR1PM5+OTJpCcOqDV3+4NZjmT2d+v1xXjI+Supqd1Edi039Gq3/xBJuuolN8HPp2fjHXZQCU56VTKGnbogpMGUZoyunHhyXytHUJTse8O3IZPzP+JYe/3xyJUT+lTaBJTZQ95yUhSCP4QfiXSk5XkuhKlebKTP8/iQevy+LdYqiU6TkZQOL5qkXhHPauhQPeZrQTcfAN8hkjEHECIGj0frjHZrPIaYrCxURMp4/Kbd7x4EE93liJHEqFEVQFCsH0k+MbJ8y1WzyFRVqKrYOJRGc7iZSMb2oUqYNOR4KmMRuXEIATNp6pnSznniUq5zNqe9vigUXtwA9g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1803; X-JNPR-Received-From: outside X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1803; 20:SZv2LvpnNy6fQ3NCMyhNEfgDQlEObCwQ3DNwLFJZKBDRISrYW8JpQ2le7uO72Fae2FBVPTGeNzndef9NM6O1lycv5JunOkEF8JIsX0YUJ1iCxgcpBG58KfqVaRKVJUf88CxzASB5vNxOeYuCpWLEjZISeKQC6wGk+0rVtNxEgD9n5XI6ZdGo4Qs2WaZSYlwocFtKyIScxitrY/xUOnVef7YiS38ifxbbyx6EpXhYKGkwASnFzLCyvh3EmLDYGSkE4LNYzVNgzxFdEnsfNVgTdRfTYaifPRojsfdaEAFJpPZ+s+ECqj7MuVezDQzF5zV74Fkgb0grcEt5lfU9tS/qZtXMuzFrJ6VgPj0ebWrsvC3k9d5o/mBhnO0lisO9iqf+xtRP8HGTWdGmPgJKqqRfj6OrueU5tTdozAySSdGoJn/SFL7WvHjiCkHkJENFn0acr39Nt9IpJZlD5+LQxp+idtO+O/yHlVtPzXRIX0tbtJo9Zq8AYgui9RD6GGS95wRx X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(13015025)(13017025)(13024025)(5005006)(8121501046)(13023025)(10201501046)(3002001); SRVR:CY1PR0501MB1803; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1803; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1803; 4:8kA2rGkIIpgBXzTH9xXlB+PwOkCQ+hQ4sbNfW+8B10E2y10wrO6PWwNM3fzL9oXIfj79IlqpIfkJCcuk+Th6Cp3bOJnipB+dFGzdaiXybJMdnwTRPhP5RO9spD17fBTKS7DanVpHaVV7NHZR7YTcHPM5XKqkwp2ePeDlS+iS86STh7/F1af9ZcY6h8njlpHlIzHeiOzbVp7dO4opOpOdJ4n7Gg280yxkCAqPXT7Zrq4Tif7BNfHEgQcHl8BJZBo0iKa4wwquBHZ24WIyN3fDc1/lSVYzGaBonJZQrVMpPy8wCFBKsB5s4zu0Om6aO1fsukekovIjvyTcllClCGBwwNKEkOi1RBu0PJUshDA3Aq+pybCJZFDBKeEloXhoJh2lAwxjbj1rTWjKsAXZZMx6W/OodExKBmMxamNqdgNPQEvj3CT1Il5dm7cfF5CFnVQxqlt+kSIJemY0hb+3Fw4Gdw== X-Forefront-PRVS: 08770259B4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1803; 23:925aX9tU3cTh1ElNXxaH4MFxdpJshNq4wSPsl6E?= =?us-ascii?Q?iOPAOUTcb2CGXsQSrnJJR0pSUwNNk3NlDpo1pB8CMWoqWbyyyEuQi/+IACQB?= =?us-ascii?Q?f0cOPExPXUDV1qXq2xdscQ2/wBZHoXwZXdwLxRM4YzQ7GXIGLXo8yzYlJ9d1?= =?us-ascii?Q?kzNHRzxUBwonXN7wXYCZsFGpHcp76OOMWPDUXJv0yXu75Io3txIhstyRmDBM?= =?us-ascii?Q?7BMQvbxAr5PZhXuTneu5fu/P9ROGINZHNQBkQzMZXTutJOKpNxsbZW8hptBb?= =?us-ascii?Q?67RaLmFIAvhW4vA4qMq5TXO23kOrN4d8FuWs/BzAuUbc0VyiM/JhKIx2ga7l?= =?us-ascii?Q?5oYB16m/NxeqZEyIex4Xa+94P2dLDmraMKzvhii0SITYVoP5WrLPnhgasEcq?= =?us-ascii?Q?f++XIPHC7Zsesl/JU5C5w+4hbM8gcsX3cmOwDf1LogVQ6lq2RkbapUasVQj+?= =?us-ascii?Q?6Ldsml1VQpS1j/uDMhAiGht+D/fVAIlb2WRKGrJYTGA9IMJp8fbedCsgCrMr?= =?us-ascii?Q?wNs5qEpG2BJvGRfR+4xd/tCSuV0Mw05wLA6fwW+I3B9KINPjOf0GzMz8WDOB?= =?us-ascii?Q?ByrT6LPjAkwVIJWoHj2TihgjKd15CsZPrNNYTJjUep/m+qsss0TUMak1YvM5?= =?us-ascii?Q?JHseRuQoTNo3F1BDJuECuzKZfD1j9Qj0gwhY5K0CVpo3d3WH14Rn9nhnLKAk?= =?us-ascii?Q?cCDSbjeJ3welMKxNrLd9mBH8ykmM8oeY4bdvAk49vZvvbmu6PIgsCAn6BoD0?= =?us-ascii?Q?tR37hmtBHBcANwdHlmKIT+9cc9I8CrzddM0vZXQXeXXyWLbccFXjY5yQyXjM?= =?us-ascii?Q?JAq1nQKyCPuaup+VBIDMiQXUz3/QjTNQoL0k7g6BIyUKA+Tgp9WPBobsmbfn?= =?us-ascii?Q?J9RRGA16/QfERJx7w/faiXN/kr5Xxfd+tCh2o+RbIhQAFvR6XyIXEVzy3Yhy?= =?us-ascii?Q?VM3Gr/8kQViHSuW3mWHY7Z3NWXpOwqycbxcdcDA8tLviY2I7QKwrT62VADR2?= =?us-ascii?Q?2gHHNgNiQGqlpCsXiwIHqzh0dknsSdGBRRUFavE71AyiK8tm8lU/jr1QjcVC?= =?us-ascii?Q?dMpnH59o/REOr6Bg6qEtdr3r1AXr6jk5qNdDGnziyGd3a9bfnlpj3gEn68Fw?= =?us-ascii?Q?W8QVCa4BGOq4XZsVH6NHJUC45KaBoaM5e7XVGU5qy3yQt1u6/dbrPag=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1803; 5:ET8xKJl8JM4dV6rIGOKSRI3k1THBYmSUkDD67gyDZSz9s5FHFWFK+duHZZoh8VkD4ZfGsLfTJxGG+s2kF9F5WHH8qhttC3Kem1e+UJs6s62uAG+Ng5HuB675NkJm8M2TrBD1dNrkQ8TM5+XF9ZU3HQ==; 24:0eZ/Eah2L+gx/GmfBpHM7gkMDcXkVH96YkPcFrlrsoB7a2+omDgPIQiObc4G9SJ1C42z2Lur2vC1xnhRmN7SOvSEW7TjYWd65AVTBxzMDLg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2016 17:03:11.0611 (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: CY1PR0501MB1803 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 17:36:37 -0000 Reminder: if you are attending, the meeting is today (now). Jonathan 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. > >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 >_______________________________________________ >freebsd-transport@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-transport >To unsubscribe, send any mail to >"freebsd-transport-unsubscribe@freebsd.org"