From owner-freebsd-transport@freebsd.org Fri Oct 30 14:41:47 2015 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 F2336A1EF06 for ; Fri, 30 Oct 2015 14:41:47 +0000 (UTC) (envelope-from jlooney@juniper.net) 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 BB99914C2 for ; Fri, 30 Oct 2015 14:41:47 +0000 (UTC) (envelope-from jlooney@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id BB2ECA1EF05; Fri, 30 Oct 2015 14:41:47 +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 BABC3A1EF04 for ; Fri, 30 Oct 2015 14:41:47 +0000 (UTC) (envelope-from jlooney@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0140.outbound.protection.outlook.com [157.56.110.140]) (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 6B0CD14C1 for ; Fri, 30 Oct 2015 14:41:46 +0000 (UTC) (envelope-from jlooney@juniper.net) Received: from BLUPR05MB1971.namprd05.prod.outlook.com (10.162.224.25) by BLUPR05MB1972.namprd05.prod.outlook.com (10.162.224.26) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 30 Oct 2015 13:09:23 +0000 Received: from BLUPR05MB1971.namprd05.prod.outlook.com ([10.162.224.25]) by BLUPR05MB1971.namprd05.prod.outlook.com ([10.162.224.25]) with mapi id 15.01.0312.014; Fri, 30 Oct 2015 13:09:23 +0000 From: Jonathan Looney To: hiren panchasara , Randall Stewart CC: FreeBSD Transports Subject: Re: Maintaining dupack counter per hole (was: The trouble with sack..) Thread-Topic: Maintaining dupack counter per hole (was: The trouble with sack..) Thread-Index: AQHREtukPt6xEWx9x06P2pRt2Ui3Kp6Dv5mA Date: Fri, 30 Oct 2015 13:09:23 +0000 Message-ID: References: <20151030062423.GB5261@strugglingcoder.info> In-Reply-To: <20151030062423.GB5261@strugglingcoder.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jlooney@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1972; 5:CwpbNEb9tiEY0Fhav9NU3Kvh0nZopPSnUE9M/mRbJBt/AQNwC8dgFPlChvYWft24/15x3y5dAMwscCPu6N+g++Y/AtbqOEZ9wf4zR6iZlAZUVn7o9crWig9wuW/yemxarzsp6Kza3NkHVynNgk43Qg==; 24:iIvPBnFSIftptk8Y8bxi2mTZ5bt+E3RT8+6EApLBdY3rD4zV1XjYAaW5L07sg6JQVOtIPW41poLmuRiuzjej7LfJj36xC3iPWIv4nZ6wt2Y=; 20:0TZgsGv3uYSfrLxAWGfF/mt0PjyGhkE0I30KhyPjnhyuj5l1fJM+PJM1KyXfu72Wr5Of15woZ6PhQW1+eh0S3Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1972; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(102215026); SRVR:BLUPR05MB1972; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1972; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(24454002)(479174004)(199003)(4001350100001)(87936001)(5002640100001)(10400500002)(5001770100001)(5008740100001)(101416001)(2900100001)(2950100001)(97736004)(5001960100002)(189998001)(92566002)(102836002)(77096005)(81156007)(5004730100002)(19580405001)(5007970100001)(11100500001)(40100003)(105586002)(99286002)(66066001)(76176999)(83506001)(106356001)(122556002)(19580395003)(86362001)(106116001)(50986999)(54356999)(36756003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1972; H:BLUPR05MB1971.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <6F4D6B5447E08546B0F42B5DF84458C3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2015 13:09:23.0451 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1972 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: Fri, 30 Oct 2015 14:41:48 -0000 On 10/30/15, 2:24 AM, "hiren panchasara" wrote: >(Something Randall and I discussed today) > >On 10/07/15 at 12:17P, Randall Stewart via freebsd-transport wrote: >>=20 >> 3) When we have more than one hole the goal of SACK was to retransmit >>every time that >> a hole had 3 dup-acks so that one could recover multiple blocks >>that were lost. We just >> plain don?t track dup-acks per hole. We do continue to count, but >>we will wait to retransmit >> anything until after we have drained 1/2 the data in flight from >>the network at a minimum. And only then >> do we start incrementing cwnd (remember we crashed it to 1 MTU) so >>that we can retransmit. There >> may be some other twists in the code that we are missing but this >>is what we believe (this could could >> probably win the C obfuscation contest if someone were willing to >>enter it :-D) > >Wondering if we can add this dupack counter in struct sackhole {} and >every time we process acks with sack in tcp_sack_doack(), we increment >this counter if the same hole appears again. And retransmit it on (or >after?) 3rd dupack. The SACK hole-tracking code is already quite complex. If we're going to make a fundamental change, perhaps it is time to consider a rewrite, rather than a smaller patch? Maybe this is the best code we can write. Or, maybe it is time for a re-coding to make it more easily accessible. In any case, how do you propose tracking holes that are carved up by later packets? E.g. Hole is 1:1500. Then, you receive a packet with 500:750, leaving two holes. Then, you receive a packet with 1000:1250, leaving three holes. Do you charge all three holes with the duplicate ACKs? Do you copy the counter to the holes? Or, is the fact that the ACK is slightly different enough to reset the counter? If you reset the counter anytime the hole is broken up, it will take a while to get to three in a really out-of-order network scenario. On the other hand, if you don't reset the counter, you may retransmit too fast. Just my initial reaction... Jonathan