Date: Mon, 16 Nov 2015 10:06:44 -0800 From: hiren panchasara <hiren@strugglingcoder.info> To: Jonathan Looney <jlooney@juniper.net> Cc: Randall Stewart <rrs@netflix.com>, FreeBSD Transports <transport@FreeBSD.org> Subject: Re: Maintaining dupack counter per hole (was: The trouble with sack..) Message-ID: <20151116180644.GU29829@strugglingcoder.info> In-Reply-To: <D258E1AC.4A234%jlooney@juniper.net> References: <DA8A5844-8F11-42D5-B923-3F329203B867@netflix.com> <20151030062423.GB5261@strugglingcoder.info> <D258E1AC.4A234%jlooney@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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"
> <owner-freebsd-transport@freebsd.org on behalf of
> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151116180644.GU29829>