[Cake] when did rack enter the kernel?

[Cake] when did rack enter the kernel?

[Dave Taht]

https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cake] when did rack enter the kernel?

[Andrew Shewmaker]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

On Mon, Jul 18, 2016 at 3:05 AM, Dave Taht <dave.taht@gmail.com> wrote:

> https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf


10 Jan 2016

https://kernelnewbies.org/Linux_4.4#head-2583c31a65e6592bef9af426a78940078df7f630

​The draft was significantly updated this month.

https://tools.ietf.org/html/draft-cheng-tcpm-rack-01​

-- 
Andrew Shewmaker

[-- Attachment #2: Type: text/html, Size: 1632 bytes --]

Re: [Cake] when did rack enter the kernel?

[Neil Shepperd]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

October 2015:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb9fae328faff9807a4ab5c1834b19f34dd155d4

Sounds like the speed up is pretty subtle, so I'm not surprised I didn't
notice...
On Mon, 18 Jul 2016 at 05:05 Dave Taht <dave.taht@gmail.com> wrote:

> https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf
>
> --
> Dave Täht
> 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
>

[-- Attachment #2: Type: text/html, Size: 1533 bytes --]

Re: [Cake] when did rack enter the kernel?

[Dave Taht]

On Mon, Jul 18, 2016 at 5:05 PM, Neil Shepperd <nshepperd@gmail.com> wrote:
> October 2015:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb9fae328faff9807a4ab5c1834b19f34dd155d4
>
> Sounds like the speed up is pretty subtle, so I'm not surprised I didn't
> notice...

It is not so much the speed ups in loss recovery in rack that are
concerning me, it is the impact on congestion avoidance (which is sort
of undefined in the ietf draft). I have been observing a dramatic
decline in observed packet loss and a sluggishness in grabbing newly
available bandwidth - as well as oddities when congestion avoidance is
hit after exiting slow start. I was looking at traces and not seeing
the window open up at all...  even with reno... as well as one where I
was seeing queues drain completely and a loss of utilization at 10mbit
in cake.

Regrettably I have so many different pieces in flight (cake, wifi
device drivers, now this) that taking a few steps back to look at the
issues seems to be needed. Are we really tracking dropped packets
correctly?

So I can add a new one - What happens if I disable rack and/or test
with an older kernel?

> On Mon, 18 Jul 2016 at 05:05 Dave Taht <dave.taht@gmail.com> wrote:
>>
>> https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf
>>
>> --
>> Dave Täht
>> 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



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cake] when did rack enter the kernel?

[Mario Ferreira]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

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=eb9fae328faff9807a4ab5c1834b19f34dd155d4

Yuchung Cheng says:
==================== 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 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.
==================== Signed-off-by: David S. Miller <davem@davemloft.net>

On Mon, Jul 18, 2016 at 6:05 AM Dave Taht <dave.taht@gmail.com> wrote:

> https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf
>
> --
> Dave Täht
> 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
>
-- 

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

[-- Attachment #2: Type: text/html, Size: 4386 bytes --]