[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)
- [tcpm] Editorial comments for draft-ietf-tcpm-rac… Gorry Fairhurst
- Re: [tcpm] Editorial comments for draft-ietf-tcpm… Rodney W. Grimes
- Re: [tcpm] Editorial comments for draft-ietf-tcpm… Yuchung Cheng