Re: [tcpm] [EXTERNAL] WGLC for draft-ietf-tcpm-rack-08

[Praveen Balasubramanian <[e-mail]>]

We reviewed the latest version of RACK as a part of the TCPM WGLC and this is some feedback: 

Section 5 Requirements
>>  For each packet sent, the sender MUST store its most recent transmission time 
It is important to call out that in practice for sends that are batched together in time, an implementation may choose to keep per-send transmission timestamps instead of per-packet. This improves memory efficiency. The way the RFC requirement is worded it seems to exclude such an optimization. 

Section 4 Design Rationale for Reordering Tolerance
>>If RACK becomes widely deployed, the underlying networks may introduce more reordering for higher throughput.
A better word here would be universally deployed because otherwise networks would be unfairly harming TCP stacks that have not deployed RACK. Plus as pointed out, reordering puts other strains on the network including ECMP, RSS, hardware offloads etc. Consider removing any recommendations for networks from this draft to prevent any unintentional relaxing of requirements on networks. This section should ideally only focus on why RACK chooses to relax reordering requirements as they pertain to loss detection and recovery. 

>>temporarily override the reorder window
Nit: Let's consistently call this reordering window throughout the draft.


Section 7.2 Upon receiving an ACK   Step 5.
>>For timely loss detection, the sender MAY install a "reordering settling" timer set to fire at the earliest moment at which it is safe to conclude that some packet is lost.
At least in lab tests this timer seems to make a big difference. Recommend changing this to a SHOULD instead of MAY.

>>This can be implemented by using a seperate doubly-linked list sorted in time order.
Typo separate. We shouldn't recommend a specific data structure. 

Some questions that need more explanation: 
1. What about TLP and its relationship to Limited Transmit? Both of them are techniques trying to solve the same problem. Its important to clarify whether Limited Transmit is left unchanged from RFC 6675. It is also unclear whether Limited Transmit should be upgraded from a MAY to a SHOULD. The non-SACK case might benefit from Limited Transmit? 
2. Why does TLP require SACK? In the case SACK negotiation fails, or SACK blocks are stripped in the network, TLP may still recover faster than an RTO when FlightSize is 1.


-----Original Message-----
From: tcpm <[e-mail]> On Behalf Of Michael Tuexen
Sent: Monday, March 30, 2020 3:28 PM
To: tcpm IETF list <[e-mail]>
Subject: [EXTERNAL] [tcpm] WGLC for draft-ietf-tcpm-rack-08

Dear all,

just a quick reminder:

We are currently running a WGLC for TCP RACK until Tuesday, April 7th 2020.

Please send any comments, including indications to support this document, to the TCMP mailing list by then.

The ID is available at
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-rack-08&amp;data=02%7C01%7Cpravb%40microsoft.com%7C0f4389073900466c89c408d7d4f9b460%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212041259507026&amp;sdata=nQghPe61ph4EBThh4xRYp9LTmfisCp6LZAj96leSpOI%3D&amp;reserved=0

Best regards
Michael