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

[Yuchung Cheng <[e-mail]>]

On Fri, Jul 24, 2020 at 1:16 PM Theresa Enghardt <[e-mail]> wrote:
>
> Dear Yuchung,
>
> Thank you for the reply and for posting a new draft.
>
> I read the current version -09 and find that it has greatly improved
> clarity and readability.
thanks for taking another look!

>
> This resolves most of my comments.
>
> Just one reply and a few additional minor comments:
>
> On 2020-07-13 15:06, Yuchung Cheng wrote:
>
> > […] The new
> > subsection 'RACK reordering window adaptation explicitly lists the
> > rules of 3-dupacks and reordering window.
> > When the reordering window is zero, RACK will mark the first unacked
> > packet lost on the first DUPACK. The rule is to hold up until the
> > third DUPACK (or 3 MSS worth of bytes been sacked).
>
> This helps, thanks.
>
> 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).



>
> An alternative (and probably false) way of reading this would be that
> the SHOULD just means that the sender should expect the reordering
> window to be 0.
> But it doesn't seem logical to me to use SHOULD in this way.
>
> (This is probably clarified later in the detailed algorithm, but it
> would be nice to have this phrased clearly in this Section as well.)
>
>
> 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?

>
> Nits / Editorial comments:
>
> In Section 2.2 and Section 3.3.2., the numbered list goes "1.", "1.",
> "2.", but should be "1.", "2.", "3.".
will fix
>
> In Section 4, list item 2. might have an unnecessary "that":
> "[…] timestamp whose granularity that is finer than 1/4 of the minimum
> RTT of the connection."
will fix.
>
>
> Best,
> Theresa