From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CB6323B25D for ; Sat, 30 Jul 2016 09:53:18 -0400 (EDT) Received: by mail-it0-x236.google.com with SMTP id u186so213715575ita.0 for ; Sat, 30 Jul 2016 06:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DcwNqSPygyYK8Zb0JVOADPosMPBvF0Mjj1AIWjCiYjI=; b=aLW4it3f6Sxjd5tIHj864VpFOUGMmyTU/WQe5iq6y6k3fsAbDauFq+54AxNpLUyj6+ S69l/VJA62MPL30AylcW7DxqRHyEm1lW4yKnoOYlaDzLaKueAg9hdQbMqOt/6k0bty// xTtbwSQ7Vz+S/7nzW3mxMyARE0D8tyIooHZhyVVQCoJrH4YXBKx5oImxF6RmnI/hTP4d BDsOfJJJyJSU2FBwH1SD4T9VUVbsuC0RncojssyTEMvHFI4gNukWhfXKHrCP+v/Y4r0f /n4STnXm9FMAHW0M/m0FohSpoHOFjt82Tw5CfJld8/o9GXDUVVUli18XFRdz8H7tf59f gVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DcwNqSPygyYK8Zb0JVOADPosMPBvF0Mjj1AIWjCiYjI=; b=OVBL96ibD2ZI9IAF3EYBJmETRfwkpplwNVC1vR/K+pBXSZfVvSewcgkeamdWijiaE8 fJd+XTD6Jt8mEyUxOIuuEKpEGpghC/fkkIlRpYDB8uOAaNM1YyROVDWEizKbfuoyq97j Elr2f6BAtfy2cUY9bbxbXJPhyDqe2hGBF98Y1CdEFos+dI+16HDBKAOpYHXGliFmCn8y 3Rbz7gDdxu5VjOGuXMpjXaX0tPf++Dr4Wpm6nEN8uvcc0LyFPa2oWcZgnGegTOUa3beT WrQTZZSBv8kkS8lmbWXrfpWQv/iOJT8W72A4tu+NdsNuVQRHpnBjjBQrXEXh/siyYriT IeHA== X-Gm-Message-State: AEkoouvLKkY/Z0njkOHO5hLhl1HmYP+Mjjn57ZNNdiJPljv7rUrTY/U5cfzdyXkTM1Jwi0NjSBvaNYVn9fPdeA== X-Received: by 10.36.73.230 with SMTP id e99mr53710400itd.36.1469886798203; Sat, 30 Jul 2016 06:53:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mario Ferreira Date: Sat, 30 Jul 2016 13:53:08 +0000 Message-ID: To: Dave Taht , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a11c14bea77a7940538dab04d Subject: Re: [Cake] when did rack enter the kernel? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 13:53:18 -0000 --001a11c14bea77a7940538dab04d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's mentioned on https://kernelnewbies.org/Linux_4.4 No idea about it's status though. It was added on 2015-10-21 as per https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= =3Deb9fae328faff9807a4ab5c1834b19f34dd155d4 Yuchung Cheng says: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RACK loss dete= ction RACK (Recent ACK) loss recovery uses the notion of time instead of packet sequence (FACK) or counts (dupthresh). It's inspired by the FACK heuristic in tcp_mark_lost_retrans(): when a limited transmit (new data packet) is sacked in recovery, then any retransmission sent before that newly sacked packet was sent must have been lost, since at least one round trip time has elapsed. But that existing heuristic from tcp_mark_lost_retrans() has several limitations: 1) it can't detect tail drops since it depends on limited transmit 2) it's disabled upon reordering (assumes no reordering) 3) it's only enabled in fast recovery but not timeout recovery RACK addresses these limitations with a core idea: an unacknowledged packet P1 is deemed lost if a packet P2 that was sent later is is s/acked, since at least one round trip has passed. Since RACK cares about the time sequence instead of the data sequence of packets, it can detect tail drops when a later retransmission is s/acked, while FACK or dupthresh can't. For reordering RACK uses a dynamically adjusted reordering window ("reo_wnd") to reduce false positives on ever (small) degree of reordering, similar to the delayed Early Retransmit. In the current patch set RACK is only a supplemental loss detection and does not trigger fast recovery. However we are developing RACK to replace or consolidate FACK/dupthresh, early retransmit, and thin-dupack. These heuristics all implicitly bear the time notion. For example, the delayed Early Retransmit is simply applying RACK to trigger the fast recovery with small inflight. RACK requires measuring the minimum RTT. Tracking a global min is less robust due to traffic engineering pathing changes. Therefore it uses a windowed filter by Kathleen Nichols. The min RTT can also be useful for various other purposes like congestion control or stat monitoring. This patch has been used on Google servers for well over 1 year. RACK has also been implemented in the QUIC protocol. We are submitting an IETF draft as well. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Signed-off-by:= David S. Miller On Mon, Jul 18, 2016 at 6:05 AM Dave Taht wrote: > https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --=20 Mario S F Ferreira - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature --001a11c14bea77a7940538dab04d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

No idea about it= 9;s status though.

It was added on 2015-10-21 as = per


= Yuchung Cheng says:
<= div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D RACK loss detection RACK (Recent ACK) loss recovery uses the notion of time instead of packet sequence (FACK) or counts (dupthresh). It's inspired by the FACK heuristic in tcp_mark_lost_retrans(): when a limited transmit (new data packet) is sacked in recovery, then any retransmission sent before that newly sacked packet was sent must have been lost, since at least one round trip time has elapsed. But that existing heuristic from tcp_mark_lost_retrans() has several limitations: 1) it can't detect tail drops since it depends on limited transmit 2) it's disabled upon reordering (assumes no reordering) 3) it's only enabled in fast recovery but not timeout recovery RACK addresses these limitations with a core idea: an unacknowledged packet P1 is deemed lost if a packet P2 that was sent later is is s/acked, since at least one round trip has passed. Since RACK cares about the time sequence instead of the data sequence of packets, it can detect tail drops when a later retransmission is s/acked, while FACK or dupthresh can't. For reordering RACK uses a dynamically adjusted reordering window ("reo_wnd") to reduce fals= e positives on ever (small) degree of reordering, similar to the delayed Early Retransmit. In the current patch set RACK is only a supplemental loss detection and does not trigger fast recovery. However we are developing RACK to replace or consolidate FACK/dupthresh, early retransmit, and thin-dupack. These heuristics all implicitly bear the time notion. For example, the delayed Early Retransmit is simply applying RACK to trigger the fast recovery with small inflight. RACK requires measuring the minimum RTT. Tracking a global min is less robust due to traffic engineering pathing changes. Therefore it uses a windowed filter by Kathleen Nichols. The min RTT can also be useful for various other purposes like congestion control or stat monitoring. This patch has been used on Google servers for well over 1 year. RACK has also been implemented in the QUIC protocol. We are submitting an IETF draft as well. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Signed-off-by: David S. Miller <d= avem@davemloft.net>=C2=A0=C2=A0

On Mon, Jul 18, 2016 at 6:05 AM Dave Taht= <dave.taht@gmail.com> wro= te:
https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf<= br>
--
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
ht= tp://blog.cerowrt.org
_______________________________________________
Cake mailing list
Cake@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
--

Mario S F Ferreira - Brazil -= "I guess this is a=C2=A0signature."
feature, n: a documented bug | bug, n: an undocumented feature

--001a11c14bea77a7940538dab04d--