[tcpm] Editorial comments for draft-ietf-tcpm-rack-09:

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 18 August 2020 13:45 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7621D3A0A3D for <tcpm@ietfa.amsl.com>; Tue, 18 Aug 2020 06:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLtQKs2XwntG for <tcpm@ietfa.amsl.com>; Tue, 18 Aug 2020 06:44:58 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id EAC083A0A38 for <tcpm@ietf.org>; Tue, 18 Aug 2020 06:44:57 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 47BA71B000A6; Tue, 18 Aug 2020 14:44:54 +0100 (BST)
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: tcpm IETF list <tcpm@ietf.org>, "ycheng@google.com >> Yuchung Cheng" <ycheng@google.com>
Message-ID: <a2d6adb9-c150-7351-285e-406ddd6a6904@erg.abdn.ac.uk>
Date: Tue, 18 Aug 2020 14:44:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/bto_wVB-4m8RlHrt6Ab-IKUIKbI>
Subject: [tcpm] Editorial comments for draft-ietf-tcpm-rack-09:
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2020 13:45:01 -0000

I have previsously sent a few comments on draft-ietf-tcpm-rack-09  and 
this email contains only issues that I think are likely editorial, but I 
hope will help in prep of the next rev.

Best wishes,

Gorry

---

“Heavy congestion or traffic policers can cause retransmissions to be 
lost again.”
- I think this is probably clear, but it might be easier if it said:
“Heavy congestion or traffic policers can cause the retransmitted 
packets to again be lost.”
—
“To mitigate the issue, [RFC4653] adjusts DupThresh to half of the 
inflight size to tolerate higher degree of reordering.”
- Maybe should insert /the/ or /a/ before /higher/?
—
“and widely-deployed SACK options”
- could you please insert a REF to relevant SACK RFCs.
—
“one alternative is to
    dynamically adapt DupThresh based on the FlightSize (e.g. adjusts
    DUPTRESH to half of the FlightSize).”
- should the latter part be “(e.g., the sender adjusts the DUPTRESH to 
half of the FlightSize).”
—
“The RACK reordering window adapts to the measured duration of
    reordering events, within reasonable and specific bounds in order to
    disincentivize excessive reordering. “
- for the avoidance of possible misreading, could we remove /in order/, 
since this would still seem ti read correctly and prevent someone 
thinking about ordering issues.
—
In section 3.3.2. I see some sub-items numbered within a numbered list, 
which is confusing - could bullets be used for the two sub items.? The 
list also appears to resume with “1.” again - is this correct?
—
“The rationale is that spurious retransmissions for short flows are not 
expected to produce excessive network traffic additionally. “
- Does this read correctly? should it be /excessive additional network 
traffic/
—

Figure 1 could benefit from a caption?
—
I wasn’t confused by:
“For cases where the reordering degree is larger
    than the default DupThresh of 3 packets”
- but elsewhere the DupThresh is discussed in terms of segments!
—
/keeps a SACK scoreboard information/
- should this be:
- /keeps SACK scoreboard information/
—
Section 5 interchanges segments and packets, I was not confused. Maybe 
you could just add one sentence at the start that explains this?
——
/before resetting RACK.reo_wnd/
- add a period at the end of the line.
—
/updates its states that tracks /
- should be:
/updates the states that track /
- or /state/.
—
/ Therefore, RACK
    persists the inflated RACK.reo_wnd for only 16 loss recoveries/
- could be: / Therefore, RACK
    persists using the inflated RACK.reo_wnd to recover up to 16 losses/
—

/(e.g,/
should be
/(e.g.,/
—
/This segment is chosen in order to deal with the
    retransmission ambiguity problem in TCP./
-  could we also remove /in order/, since this would still seem oi read 
correctly and prevent someone thinking about ordering issues.
—
/waits for the RACK reordering window expire,/
- insert /to/ before /expire/.
—
/just as it would
    with any other ack/
- should this be /ACK/?
—
/MUST not be retransmitted until congestion control deems this appropriate./
- seems to be /MUST NOT/.
---

/even if the congestion window is full./
- could this be:
- /even if the congestion window is fully used./
---

8.5 mentions Sprout - which to me seems a spurious and unecessary 
reference? However, I really think the WG should have mentioned the 
previously proposed reordering protection in TCP-NCR (RFC4653)