From owner-freebsd-transport@freebsd.org Fri Oct 30 16:50:54 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 AF40FA2190F for ; Fri, 30 Oct 2015 16:50:54 +0000 (UTC) (envelope-from rrs@netflix.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 84389133C for ; Fri, 30 Oct 2015 16:50:54 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 818D6A2190E; Fri, 30 Oct 2015 16:50:54 +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 81143A2190D for ; Fri, 30 Oct 2015 16:50:54 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 48E48133B for ; Fri, 30 Oct 2015 16:50:54 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by padhy1 with SMTP id hy1so73216653pad.0 for ; Fri, 30 Oct 2015 09:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6WlQ8gdl38QAbl6G+SE5pjgFSoBortSgIcbd4Tgsijo=; b=Aw/2PX0oMiadRPvj1yi+ee5XSJxT9kyNm0gda5/ox006mu4G0Tmwx1rYkgrMtQ7Gao lC4i98g2Bz0Vse9mZiUx87rBUp3jxRpGmDbKNPAgM8esTpWPYcN70kOYiWSuabLmFizP 6VT9ZbHDxYrRNxjUIK09I1MwCC3b2eg6GUUbg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6WlQ8gdl38QAbl6G+SE5pjgFSoBortSgIcbd4Tgsijo=; b=lEOKYu8O9wFp+cMBGb/4NtrdCIAR/HZBLgl+mdhJHx7y4KrX+TCx1yr0hY0h2M+uca D17mrjIIKIiUYbXZNyxFLlnH13vIZlFDVWp0T0nn/bmR6RrXXvpKYxhB4bCiWMWQZBCg O5dRpnBGYmUzyV17SeeD9GXTV5k9kNUDqvwfZU0SZ9QDBzhH1ahliK0cRlXfSxv0TKcN r1Yy9STv/mhU9XDctCZZUwW//TtdfszxaXxqhvo5e00Armxaxc4c/X2UrtL3CoR4J8a+ mWr+JPF5HDb6SCxzEjf1XaavJOBbylQR+tQFItDQx5AUc/LDVko1mIklrvuhuG50nYZ8 mYlA== X-Gm-Message-State: ALoCoQl1UbN/qdJwWQBgdQGUU4F2D1XQNKtwFqMfGZ6jRFsv1KRvnj0xSez0oJoOCYOv+nxozALY X-Received: by 10.68.65.42 with SMTP id u10mr9935096pbs.8.1446223853706; Fri, 30 Oct 2015 09:50:53 -0700 (PDT) Received: from [10.16.208.207] ([69.53.232.0]) by smtp.gmail.com with ESMTPSA id bo5sm9104925pbb.76.2015.10.30.09.50.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Oct 2015 09:50:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Maintaining dupack counter per hole (was: The trouble with sack..) From: Randall Stewart In-Reply-To: Date: Fri, 30 Oct 2015 09:50:56 -0700 Cc: hiren panchasara , FreeBSD Transports Message-Id: <4C66DD2E-DFD0-4334-B14F-16289DC82A41@netflix.com> References: <20151030062423.GB5261@strugglingcoder.info> To: Jonathan Looney X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 16:50:54 -0000 I don=92t think you would reset the counter just because a hole was = broken up. You are either getting re-ordering in combination with TSO or possibly a retransmission which fills in some but not all of the hole.. And as to the =93rewrite=94 I am not sure its needed, its complex code I = will admit but it does seem to work. I would say only rewrite if its needed to make = the strike per hole work. Of course we need to think about this a bit more. Generally we know what = the =93new data=94 is in a SACK, so thats probably key. Hiren also pointed = out a recent Google draft to me: https://tools.ietf.org/html/draft-cheng-tcpm-rack-00 It seems to me that this is a very good thing :-) Of course there are lots of other things that need to be implemented = with it.. reorder detection being one.=20 I would imagine this is a big source of some of the gains that Quic gets = in recovery.. if you note Jana is noted in the Ack=92s section for his implementation in Quic.. R On Oct 30, 2015, at 6:09 AM, Jonathan Looney = wrote: > On 10/30/15, 2:24 AM, "hiren panchasara" > hiren@strugglingcoder.info> wrote: >=20 >> (Something Randall and I discussed today) >>=20 >> 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) >>=20 >> 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. >=20 > In any case, how do you propose tracking holes that are carved up by = later > packets? >=20 > E.g. >=20 > Hole is 1:1500. >=20 > Then, you receive a packet with 500:750, leaving two holes. >=20 > Then, you receive a packet with 1000:1250, leaving three holes. >=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? >=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. >=20 > Just my initial reaction... >=20 > Jonathan -------- Randall Stewart rrs@netflix.com 803-317-4952