From owner-freebsd-transport@freebsd.org Mon Nov 16 18:06:45 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 EB78BA30C51 for ; Mon, 16 Nov 2015 18:06:45 +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 D1F101912 for ; Mon, 16 Nov 2015 18:06:45 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id CE730A30C50; Mon, 16 Nov 2015 18:06:45 +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 B524CA30C4E for ; Mon, 16 Nov 2015 18:06:45 +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 98DE91911 for ; Mon, 16 Nov 2015 18:06:45 +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 12B7FC0479; Mon, 16 Nov 2015 10:06:44 -0800 (PST) Date: Mon, 16 Nov 2015 10:06:44 -0800 From: hiren panchasara To: Jonathan Looney Cc: Randall Stewart , FreeBSD Transports Subject: Re: Maintaining dupack counter per hole (was: The trouble with sack..) Message-ID: <20151116180644.GU29829@strugglingcoder.info> References: <20151030062423.GB5261@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MUnXZt0Uv08c1hBe" Content-Disposition: inline In-Reply-To: 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, 16 Nov 2015 18:06:46 -0000 --MUnXZt0Uv08c1hBe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Getting back to this old thread... On 10/30/15 at 01:09P, Jonathan Looney wrote: > On 10/30/15, 2:24 AM, "hiren panchasara" > hiren@strugglingcoder.info> wrote: >=20 > >(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. >=20 > 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. As Randall said (in response to this), that rewrite is not necessary. And I agree to that. I don't see tcp_sack.c being in that bad shape that it demands a rewrite. But ofc, if you have something really cleaner/faster in mind, I'm all ears. :-) >=20 > In any case, how do you propose tracking holes that are carved up by later > packets? I think this scenario is rather easy as a single hole is being carved out bellow: Let me know if I am missing anything obvious. >=20 > E.g. >=20 > Hole is 1:1500. hole1: strike=3D1 >=20 > Then, you receive a packet with 500:750, leaving two holes. subhole 1:500 strike=3D2, subhole 750:1500 strike=3D2 >=20 > Then, you receive a packet with 1000:1250, leaving three holes. subhole 1:500 strike=3D3, subhole 750:1000 strike=3D3, subhole 1250:1500 st= rike=3D3 >=20 > Do you charge all three holes with the duplicate ACKs? Do you copy the > counter to the holes? >=20 > Or, is the fact that the ACK is slightly different enough to reset the > counter? Basically, whenever a hole gets broken up, subholes carry-forward the dupack strike counter.=20 >=20 > 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. By 'too fast', I think you mean spurious retransmissions. If so, can you explain a bit more? >=20 > Just my initial reaction... Thanks you for the discussion! Cheers, Hiren --MUnXZt0Uv08c1hBe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWShsvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l3FgH/jzmsrN+a2apY3NJprFBHOrq P+xs/o2clK8A2AWJxGEwTVtZhYzQJjGgOV/vCRl7qS16RhxloaS8ywBHfZyCLdXn dFgQ8itGUPcvVYJTN1pOak3TnsO9lqFoO54YGg8SxZ7kXfzZA9Idvh+3NPUujyyw PiNSCCy/9uflUGacrgtAey8FEKM+ANBbzv5hAxQzZg8rfIliGmQ+L/UtUsER7MLE vdVbaep//Z/W7fMfhVC884nk5waU/NDnkh6tgInKJF5UztnyVbWpuBCNMJOYihqm w8m/0zW+haMnZ/QWdS97p5mwlBnhApk6JUFnnX5GTlIHfWdUVeYPxH6DX5NBeBg= =n7Tz -----END PGP SIGNATURE----- --MUnXZt0Uv08c1hBe--