Subject: [tcpm] Questions on draft-cheng-tcpm-rack-00.txt

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 19 Jan 2016 08:28:28 +0000

Hi Yuchung, Neal + others

I am currently looking into the inner details of RACK and how it coexists with  other (dupack based) loss heuristics. 
As I understand the Linux 4.4 code as well as your comment "Currently implemented to co-exist with other DupThresh heuristics" in https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-6.pdf , RACK does currently not replace the dupack heuristics ?. 
This then means that even though RACK use a reo_wnd of 10ms it can mean that fast retransmits are triggered even though the packet reordering is less than 10ms. Is my observation correct ?.

What is the implementation status in your (Google) servers ?, is it solely RACK based ?

/Ingemar
=================================
Ingemar Johansson  M.Sc. 
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com

“We can be heroes,
  just for one day”
    David Bowie 
=================================

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 19 Jan 2016 13:33:24 -0800

> This then means that even though RACK use a reo_wnd of 10ms it can mean that fast retransmits are triggered even though the packet reordering is less than 10ms. Is my observation correct ?.
That's correct. RACK is currently only used after the recovery starts
and does not start the recovery. so your scenario is possible.

btw it's one-linear kernel change to enable RACK to start recovery
(along with other tricks). I can send you the patch if you are
interested.

> What is the implementation status in your (Google) servers ?, is it solely RACK based ?
It's completely identical to the upstream kernel. No secret sauce ;-)

We have RACK-only based implementation but it's not well tested yet.
There are two challenges.

The first one is design: in a highly reordered and no loss scenario
(usually artificially crafted), dynamic dupack threshold beats RACK's
reo_wnd. This is b/c dupthresh is near the maximum cwnd that basically
turns off fast recovery. obviously it's more effective.

the second one is more of implementation: replacing 10 recovery tricks
with one has major risk. so the implementation needs to keep the
existing code as a emergency backup through sysctl change. that adds
significant complexity.

but we definitely plan to improve RACK before next meeting :-)

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 20 Jan 2016 09:47:28 +0000

Hi

Thanks for the clarification. 
I am in the process to make our proprietary LTE system simulator mimic the Linux TCP stack better. I'll be happy to see the patch to make RACK trigger the recovery state. 
And thanks for sharing the insights around the challenge for RACK, compared to "traditional" dupACK based recovery.

/Ingemar

> -----Original Message-----
> From: Yuchung Cheng [mailto:[email-masked]]
> Sent: den 19 januari 2016 22:33
> To: Ingemar Johansson S
> Cc: Neal Cardwell; [email-masked]; Karen E. E. Nielsen
> Subject: Re: Questions on draft-cheng-tcpm-rack-00.txt
> 
> > I am currently looking into the inner details of RACK and how it coexists
> with  other (dupack based) loss heuristics.
> > As I understand the Linux 4.4 code as well as your comment "Currently
> implemented to co-exist with other DupThresh heuristics" in
> https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-6.pdf , RACK
> does currently not replace the dupack heuristics ?.
> > This then means that even though RACK use a reo_wnd of 10ms it can
> mean that fast retransmits are triggered even though the packet reordering
> is less than 10ms. Is my observation correct ?.
> That's correct. RACK is currently only used after the recovery starts and does
> not start the recovery. so your scenario is possible.
> 
> btw it's one-linear kernel change to enable RACK to start recovery (along
> with other tricks). I can send you the patch if you are interested.
> 
> >
> The first one is design: in a highly reordered and no loss scenario (usually
> artificially crafted), dynamic dupack threshold beats RACK's reo_wnd. This is
> b/c dupthresh is near the maximum cwnd that basically turns off fast
> recovery. obviously it's more effective.
> 
> the second one is more of implementation: replacing 10 recovery tricks with
> one has major risk. so the implementation needs to keep the existing code
> as a emergency backup through sysctl change. that adds significant
> complexity.
>