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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Tue, 18 August 2020 14:45 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
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 C46483A0B87 for <tcpm@ietfa.amsl.com>; Tue, 18 Aug 2020 07:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Level:
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.212, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 XB3NkeEPErsb for <tcpm@ietfa.amsl.com>; Tue, 18 Aug 2020 07:45:02 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5D33A0B8B for <tcpm@ietf.org>; Tue, 18 Aug 2020 07:45:02 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 07IEiqXu065474; Tue, 18 Aug 2020 07:44:52 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 07IEiqLm065473; Tue, 18 Aug 2020 07:44:52 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202008181444.07IEiqLm065473@gndrsh.dnsmgr.net>
In-Reply-To: <a2d6adb9-c150-7351-285e-406ddd6a6904@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Date: Tue, 18 Aug 2020 07:44:52 -0700
CC: tcpm IETF list <tcpm@ietf.org>, "ycheng@google.com >> Yuchung Cheng" <ycheng@google.com>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/KqOLQKmV9FIuPWQKewBRaJQ1SJg>
Subject: Re: [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 14:45:04 -0000

Gorry, draft authros,
  Sorry to respond to a response to a draft.
  One small comment inline marked [rwg] that I feel would
  even further clean up the language.

Regards,
Rod Grimes

> 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.?

 [rwg] To me the word "again" in either of these versions does not
 add any information as this information is implied by the fact the
 "retransmitted packets" are the subject of the sentence.

 Propose:  "Heavy congestion or traffic policers can cause the
 retransmitted packets to 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 mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org