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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 18 Aug 2020 14:44:53 +0100

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)

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 18 Aug 2020 07:44:52 -0700 (PDT)

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 
> ?Heavy congestion or traffic policers can cause retransmissions to be 
> lost again.?
> ?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.?
> ?
> ?and widely-deployed SACK options?
> ?
> ?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. ?
> ?
> 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. ?
> ?
> ?
> I wasn?t confused by:
> ?For cases where the reordering degree is larger
>  ?? than the default DupThresh of 3 packets?
> ?
> ?
> ??
> ?
> ?
>  ?? persists the inflated RACK.reo_wnd for only 16 loss recoveries/
>  ?? persists using the inflated RACK.reo_wnd to recover up to 16 losses/
> ?
> 
> /(e.g,/
> should be
> /(e.g.,/
> ?
>  ?? retransmission ambiguity problem in TCP./
> -? could we also remove /in order/, since this would still seem oi read 
> ?
> ?
>  ?? with any other ack/
> ?
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 

-- 
Rod Grimes                                                 [email-masked]

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 20 Aug 2020 13:07:53 -0700

Thank you Rodney and Gorry,

We'll incorporate all your suggestions except two things:
1. RACK reordering can persist up to 16 loss recovery episodes, not 16
packet losses. This is an important difference because a loss recovery
episode (i.e. from a Fast or RTO recovery started till all the holes at the
SND.NXT when it started are repaired) can have arbitrary amount of packet
losses depending on the congestion window.

2. Sprout reference is to acknowledge a similar idea proposed from
private communication with another reviewer.

On Tue, Aug 18, 2020 at 7:45 AM Rodney W. Grimes <[email-masked]>
wrote:

> [email-masked]