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

[Yuchung Cheng <[e-mail]>]

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 <[e-mail]>
wrote:

> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> >
>
> --
> Rod Grimes
> [e-mail]
>