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

From: Michael Tuexen <[email-masked]>
Date: Sun, 1 Mar 2020 22:04:45 +0100

> On 21. Jan 2020, at 19:03, Yuchung Cheng <ycheng=[email-masked]> wrote:
> 
> On Sun, Jan 19, 2020 at 1:51 PM Scharf, Michael
> <[email-masked]> 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?
I don't think that this document updates any other RFC.
>> 
>> * 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.
What about using:

It is intended to supplement the conventional DUPACK threshold approach and its variants,
as well as other nonstandard approaches.
> 
>> 
>> * 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.
I agree with removing the paragraph.
> 
>> 
>> 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
Please remove the first sentence. The second one might be reformulated to make clear
that the 3 dup ack algorithm is somewhat integrated.
>> Thanks
>> Michael (with no hat)
Same for me...

Best regards
Michael
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 9 Mar 2020 09:10:40 +0000

These suggestions would work for me.

Michael

Von: Michael Tuexen<mailto:[email-masked]>
Gesendet: Sonntag, 1. März 2020 22:04
An: Yuchung Cheng<mailto:ycheng=[email-masked]>
Cc: Scharf, Michael<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; tcpm IETF list<mailto:[email-masked]>
Betreff: Re: [tcpm] draft-ietf-tcpm-rack - editorial impact of target PS

What about using:

Same for me...

Best regards
Michael

---

From: Neal Cardwell <[email-masked]>
Date: Mon, 9 Mar 2020 13:22:30 -0400

> > <[email-masked]> wrote:
...
> as well as other nonstandard approaches.

IMHO "supplement" is not ideal, since the intent is not to have RACK
as a supplement to ("on top of" or "in addition to") RFC6675. I do
think we intend to mean "instead of", but don't mean to imply everyone
must "replace" their RFC6675 with RACK. So I like Michael Scharf's
suggestion to use "alternative".

So how about replacing:

  It is intended to replace the conventional DUPACK threshold approach
  and its variants, as well as other nonstandard approaches.

with:

   It is intended to be an alternative to the DUPACK threshold
approach [RFC6675],
   as well as other nonstandard approaches such as FACK [FACK].

> I agree with removing the paragraph.

Removing this paragraph sounds good to me as well.

> that the 3 dup ack algorithm is somewhat integrated.

Sounds good. How about the following version?

  Since the 3 duplicate ACK threshold for triggering fast recovery [RFC5681]
  has been widely deployed and usually works well in the absence of
  reordering, RACK uses this signal to trigger fast recovery if a
  connection has not observed reordering.

neal

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Mar 2020 18:33:46 +0100

> On 9. Mar 2020, at 18:22, Neal Cardwell <[email-masked]> wrote:
> 
OK.
> Removing this paragraph sounds good to me as well.
Great.
>  connection has not observed reordering.
Sounds good to me.

Best regards
Michael