[core] Comments on draft-ietf-core-cocoa-01

[Ingemar Johansson S <[e-mail]>]

Hi

I read through draft-ietf-core-cocoa-01, and unfortunately I am not convinced that the draft its yet ready for WGLC.

In general it could be good if you can get the help from a native English speaking person to work on the text. The end result would be a more crisp text, in some cases you should even be able to remove large amounts of text, in other cases more text will likely be added.
That said.. I am definitely not worthy of throwing the first stone here, I have my own problems with the English language.

A few more detailed comments, please see them as a suggested way to improve the document, writing RFCs that describe algorithms is a pain..

Section 1 refers to two other drafts that are expired since a few years back. Isn't it better to make this draft more self- contained ?. It would of course mean that the draft becomes bigger.
Section 2 looks to me that something that belongs to section 1. There is some terminology like for instance "non-confirmable", I assume that the explanation is given in RFC7252 or one of the other CORE RFCs (sorry don't follow CORE)
Section 3 "Aggregate Congestion Control (Appendix A) is not yet supported by  research as well as the other algorithms in this specification". Ambiguous text.

Section 4
"Note that such a
   mechanism must, during idle periods, decay RTO estimates that are
   shorter or longer than the basic RTO estimate back to the basic RTO
   estimate, until fresh measurements become available again, as
   proposed in Section 4.3."
Unclear to me what this means. I don't know how the discussion has been earlier but one question that comes to my mind is.. Would it be possible to add pseudo code here and then explain the pseudo code ?.
"to avoid expending all of  its retransmissions" : Is this limitation defined?, in which draft/RFC ?

Section 4.2
Difficult to follow. Some pseudo code would help here, I believe. For example, the 1st para is very compressed.
"RTO := 0.25 * E_weak_ + 0.75 * RTO (1)"
The equation numbers should be moved further to the right to avoid confusion. In addition, I am here left wondering if these two equations are run in sequence, reading the text I get the impression that it is not the case ?.

Section 4.2.1
"If an RTO estimation is lower than 1 s or higher than 3 s, instead of
   applying a binary backoff factor in both cases, a variable backoff
   factor is used.  For RTO estimations below 1 s, the RTO for a
   retransmission is multiplied by 3, while for estimations above 3 s,
   the RTO is multiplied only by 1.5 (this updated choice of numbers to
   be verified by more simulations).  This helps to avoid that exchanges
   with small initial RTOs use up all retransmissions in a short
   interval of time and exchanges with large initial RTOs may not be
   able to carry out all retransmissions within MAX_TRANSMIT_WAIT
   (93 s)"
I would believe that it is better to describe the problem first and then the fix.

Section 4.3

"very strongly RECOMMENDED". Not sure that this will pass the IESG last call. Sounds like a "SHOULD" or "MUST"

"RTO := 1 s + (0.5 * RTO)"    the 's' confuses the reader. It should be sufficient to state that the unit of the RTO estimate is [s]



Section 5

"The confirmable messages must be sent under an RTO estimator, as

       specified in Section 4<https://tools.ietf.org/html/draft-ietf-core-cocoa-01#section-4>."

I am not sure I understand what this means.

Section 5.1

"This is relatively conservative. " Missing text ?.




Regards
Ingemar
==================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com

A mistake is to commit a misunderstanding
                     Bob Dylan
==================================