Subject: [tcpm] Fwd: New Version Notification for draft-cheng-tcpm-rack-00.txt

From: Yuchung Cheng <[email-masked]>
Date: Sat, 24 Oct 2015 09:07:17 -0700

Hi folks,

We finally put up a draft for RACK, a new loss detection.

RACK has been deployed at Google for well over a year in both TCP and
QUIC. The patches are also available for upstream Linux
(https://www.mail-archive.com/[email-masked]/msg83215.html) .
In the next -01 draft, we plan to further combine RACK with TLP (Tail
Loss Probe) because both work together well and TLP will no longer
require FACK.

Comments are welcome.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Oct 19, 2015 at 1:11 PM
Subject: New Version Notification for draft-cheng-tcpm-rack-00.txt
To: Neal Cardwell <[email-masked]>, Yuchung Cheng <[email-masked]>

A new version of I-D, draft-cheng-tcpm-rack-00.txt
has been successfully submitted by Yuchung Cheng and posted to the
IETF repository.

Name:           draft-cheng-tcpm-rack
Revision:       00
Title:          RACK: a time-based fast loss detection algorithm for TCP
Document date:  2015-10-19
Group:          Individual Submission
Pages:          12
URL:
https://www.ietf.org/internet-drafts/draft-cheng-tcpm-rack-00.txt
Status:         https://datatracker.ietf.org/doc/draft-cheng-tcpm-rack/
Htmlized:       https://tools.ietf.org/html/draft-cheng-tcpm-rack-00

Abstract:
   This document presents a new TCP loss detection algorithm called RACK
   ("Recent ACKnowledgment").  RACK uses the notion of time, instead of
   packet or sequence counts, to detect losses, for modern TCP
   implementations that can support per-packet timestamps and the
   selective acknowledgment (SACK) option.  It is intended to replace
   the conventional DUPACK threshold approach and its variants, as well
   as other nonstandard approaches.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 28 Oct 2015 16:01:13 +0000

Thanks, really interesting. 

One question . 
Quote "When the sender detects packet  reordering RACK.reo_wnd MAY be changed to RACK.min_RTT/4."
Why the value MinRTT/4 ? Is this related to TLP ?. 
One option may be to set RACK.reo_wnd according to the experienced amount of reordering but that can of course delay retransmission of lost packet.

/Ingemar

> -----Original Message-----
> From: Yuchung Cheng [mailto:[email-masked]]
> Sent: den 24 oktober 2015 18:07
> To: [email-masked] Extensions
> Cc: Neal Cardwell; Ingemar Johansson S
> Subject: Fwd: New Version Notification for draft-cheng-tcpm-rack-00.txt
> 
> Hi folks,
> 
> In the next -01 draft, we plan to further combine RACK with TLP (Tail Loss
> Probe) because both work together well and TLP will no longer require FACK.
> 
> Comments are welcome.
> 
> A new version of I-D, draft-cheng-tcpm-rack-00.txt has been successfully
> submitted by Yuchung Cheng and posted to the IETF repository.
>

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 28 Oct 2015 12:48:25 -0400

> Why the value MinRTT/4 ? Is this related to TLP ?.

Good question. The rationale is discussed in section 5.3, "Adjusting
the reordering window":

   RACK uses a quarter of minimum RTT because Linux TCP uses the same
   factor in its implementation to delay Early Retransmit [RFC5827] to
   reduce spurious loss detections in the presence of reordering, and
   experience shows that this seems to work reasonably well.

> One option may be to set RACK.reo_wnd according to
> the experienced amount of reordering but that can of course
> delay retransmission of lost packet.

Yes, we agree that investigating this kind of approach is appealing,
and this is also discussed in section 5.3, "Adjusting the reordering
window":

   One potential improvement is to further adapt the reordering window
   by measuring the degree of reordering in time, instead of packet
   distances.  But that requires storing the delivery timestamp of each
   packet.  Some scoreboard implementations currently merge SACKed
   packets together to support TSO (TCP Segmentation Offload) for faster
   scoreboard indexing.  Supporting per-packet delivery timestamps is
   difficult in such implementations.  However, we acknowledge that the
   current metric can be improved by further research.

Thanks for the feedback!

neal