Re: [tcpm] draft-ietf-tcpm-rack - editorial impact of target PS

[Yuchung Cheng <[e-mail]>]

On Sun, Jan 19, 2020 at 1:51 PM Scharf, Michael
<[e-mail]> wrote:
>
> Hi all,
>
> I briefly scanned through draft-ietf-tcpm-rack-07 regarding the impact of the new target as PS.
>
> This e-mail is only about editorial and formal issues. Note that I am not the responsible chair for this document.
>
> Questions:
>
> * Metadata: Does the document update other RFCs (such as RFC 5681)? My current thinking is that the answer is "no", but I want to cross-check. As the document now targets PS, it theoretically could update other RFCs. If the document does not update other RFCs, maybe it needs to explain this and the reason for not doing it somewhere?
>
> * Abstract: "It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches."
>
>   I am not sure if the word "replace" could be a formal issue, in particular if other RFCs are not updated by this document (see previous comment). Another wording that may work around this question could e.g. be "it is intended to be an alternative to the conventional DUPACK threshold". Do others in the working group have any opinion on that wording (in particular native speakers)?
>
>   The same question applies to later use of the word "replace".
I am fine with other wordings except I don't have a better one.

>
> * Section 4:
>
>   "This document provides a concrete and detailed reordering window
>    adaptation algorithm for implementers.  We note that the specifics of
>    the algorithm are likely to evolve over time.  But that is a separate
>    engineering optimization that's out of scope for this document."
>
>   This could be understood as an experiment... Thus, I am not sure if this wording will pass an IETF last call on standards track. I wonder if this could be reworded to something along the lines of ...

>
>   "This document provides a concrete and detailed reordering window
>    adaptation algorithm as a standard solution that is safe to use.
>    Implementers have to aware that engineering optimization of
>    the algorithm are possible."
how about we just get rid of the paragraph completely since TCP will
evolve no matter what.

>
> Section 8.4
>
>   "Nevertheless RACK is still an experimental algorithm.  Since the
>    oldest loss detection algorithm, the 3 duplicate ACK threshold
>    [RFC5681], has been standardized and widely deployed.  RACK can
>    easily and optionally support the conventional approach for
>    compatibility."
>
>   The first sentence probably should be removed. I don't really understand the second sentence. And wouldn't it make sense to better emphasize the "compatibility" earlier in the document, say, in the intro?
s.g. +1 on removing first sentence
>
> Thanks
>
> Michael (with no hat)