Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08)

[Theresa Enghardt <[e-mail]>]

Hi Yuchung,

See inline:

On 2020-07-24 16:45, Yuchung Cheng wrote:

>> On 2020-07-13 15:06, Yuchung Cheng wrote:
>> […]
>> Reading the new Section 3.3.2, I'm wondering about the following 
>> though:
>> 
>> "If the sender has not observed any reordering since the
>> connection was established, then the RACK reordering window
>> SHOULD be zero in either of the following cases: […]
>> 
>> 1.  After learning that three segments have been delivered out of
>> order (e.g. receiving 3 DUPACKs per [RFC5681]); in turn, this
>> will cause the RACK loss detection logic to trigger fast
>> recovery.
>> 
>> 2.  During fast recovery or RTO recovery."
>> 
>> Does this SHOULD mean that the implementation should set the 
>> reordering
>> window to 0 under either of the listed conditions?
> yes
> 
>> Because I fail to see how the two listed conditions mean that that 
>> "the
>> sender has not observed any reordering".
>> Or SHOULD the sender set the reordering window to 0 if either it 
>> hasn't
>> observed any reordering, or one of the listed conditions are true.
> 
> agree this can be better clarified. do you think the following is more 
> clear:
> 
> 1. The reordering window SHOULD be zero if no reordering has been
> observed on the connection so far, plus either (a)
> three segments have been delivered out of order since the last
> recovery or (b) the sender is already in fast or RTO recovery.
> Otherwise the reordering window SHOULD start from a small fraction of 
> the
> round trip time, or zero if no round trip time estimate is available.
> 
> 2.  The RACK reordering window SHOULD adaptively increase if the
> sender receives the Duplicate Selective Acknowledgement (DSACK) 
> [RFC2883],
> suggesting the window is too small which causes spurious 
> retransmission.
> 
> 3.  The RACK reordering window MUST be bounded and this bound SHOULD
> be SRTT.
> 
> (The text after this needs to be adjusted for the new bullet numbers).

This is much clearer, thanks!

Additionally, I suggest to change "The reordering window SHOULD be zero" 
to "The reordering window SHOULD be set to zero", or to prefix the 
entire list with a sentence like "More specifically, the sender sets the 
reordering window as follows:".


>> In Section 3.3.2, I fail to understand or parse the following 
>> sentence:
>> The RACK reordering window SHOULD leverage that to
>> adaptively
>> estimate the duration of reordering events, if the receiver
>> uses
>> Duplicate Selective Acknowledgement (DSACK) [RFC2883].
>> 
>> The RACK reordering window SHOULD leverage what? (If "that" refers to
>> the sentence before, SRTT, then the connection to DSACK is not obvious
>> to me. So I think it's good to substitute "that" here.)
> sorry that=DSACK. sentence got cut out accidentally. Does the proposed
> new text in my earlier comment look better?

Yes, this is clearer to me now.

I would suggest the following slight changes to this sentence though:

OLD:
"The RACK reordering window SHOULD adaptively increase if the sender 
receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], 
suggesting the window is too small which causes spurious 
retransmission."

NEW:
"The RACK reordering window SHOULD adaptively increase if the sender 
receives a Duplicate Selective Acknowledgement (DSACK) [RFC2883], 
suggesting the window is too small, which causes spurious 
retransmission."

Best,
Theresa