Subject: [core] draft-ietf-core-cocoa-01

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 2 Sep 2017 20:22:23 +0200

Hi draft-ietf-core-cocoa-01-authors, Hi all,

I have started to read the CoAP congestion control document and I have a
few comments.

One of the most important sections of a document, the introduction
section, is empty. As a reader I would find it useful
* to learn what the perceived problem is, and
* to have enough information to decide whether I want to implement this
specification.

Are there answers to these questions?

I know that there are these other referenced documents that **may**
contain some of that necessary content but do you expect the reader to
read them to understand this document? I think this document has to be
self-contained.

I also believe that many readers are worried that the enhancements to
CoAP over UDP quickly turn into CoAP over TCP. Are there suggestions on
when a deployment should switch to CoAP over TCP rather than using CoAP
over UDP with this advanced congestion control algorithm?

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 2 Sep 2017 21:11:25 +0200

Hi Hannes,

> On Sep 2, 2017, at 20:22, Hannes Tschofenig <[email-masked]> wrote:
> 

Thank you; this is very useful input.

> section, is empty.

Indeed, that is one editorial item that we need to do: extract material from the two referenced I-Ds and putting it here.  But let me try to provide concise answers to your questions here as well; we can work this into an introduction later.

> As a reader I would find it useful

The problem is that the basic congestion control (CC) provided by RFC 7252 is adaptive only in a very crude way (counting the number of retransmissions of a single message, starting fresh for every new message).  It therefore also has to be very conservative, with a basic time constant of 2 to 3 seconds (dithered).

CoCoA provides a more advanced CC, keeping some state at a message initiator about the path to the peer.  It is still very conservative, but can be less so if the path is consistently good.

What you get is a faster reaction to packet losses in cases where the actual round trip time is lower than the basic CC’s time constant.  You also get somewhat more (!) conservative behavior in a truly deteriorated situation.

> * to have enough information to decide whether I want to implement this

If you have the memory at the message initiator (per peer storage, about 4 bytes needed per peer plus the space needed to identify that peer) and the space for a few additional lines of code, you want to implement this specification.
(Note that you always can fall back to basic CC if the per-peer storage space runs out.)

> Are there answers to these questions?

There are, but we haven’t spent time on creating WG consensus about these answers.

> read them to understand this document? I think this document has to be

I agree that we shouldn’t be relying on expired I-Ds.

> CoAP over UDP quickly turn into CoAP over TCP.

Moving to TCP is a completely different class of complexity (several orders of magnitude more than just adding CoCoA).

> Are there suggestions on

The intro to CoAP over TCP gives some reasons for switching to CoAP over TCP that are unrelated to CC; these are the actual motivations that led to developing the spec.  But indeed, switching to a much more powerful transport protocol also has side benefits.

The CC benefits of CoAP over TCP as compared to CoAP over UDP are that TCP CC is much more aggressive.
(This can be a bug as well as a feature!)
If your application is an elephant and not an ant — it relies on filling up the bitrate of a path, or on getting a fair share of the total bitrate when competing with aggressive TCP flows on a congested path — you probably need TCP.  If your application needs somewhat consistent behavior in the presence of significant packet losses, then TCP doesn’t help at all (or you need a TCP implementation that is specifically tweaked beyond the standard algorithms in order to deal with this situation).

I hope this quick reaction helps you in getting your questions answered; now let’s put that information into the document as well.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 3 Sep 2017 14:59:56 +0200

Hi Carsten,

thanks for the quick response.

> The problem is that the basic congestion control (CC) provided by RFC
> 7252 is adaptive only in a very crude way (counting the number of
> retransmissions of a single message, starting fresh for every new
> message).  It therefore also has to be very conservative, with a
> basic time constant of 2 to 3 seconds (dithered).
> 
> CoCoA provides a more advanced CC, keeping some state at a message
> initiator about the path to the peer.  It is still very conservative,
> but can be less so if the path is consistently good.
> 
> What you get is a faster reaction to packet losses in cases where the
> actual round trip time is lower than the basic CC’s time constant.
> You also get somewhat more (!) conservative behavior in a truly
> deteriorated situation.
The last paragraph provides the information I had been looking for. You
may want to add this to the introduction/abstract of the draft.

The question is, however, whether the slower reaction to packet loss has
been an issue in real-world deployments.

Another related question is whether you can use typical IoT data
communication patterns for reliable RTT computations given that many
devices communicate at a regular interval but with a fair amount of
delay between the individual transmissions. Do the authors have any
traffic data from IoT deployments?

Finally, I was expecting (before reading this document) that a practical
problem is that CoAP limits the number of outstanding responses to a
given client to NSTART (1 by default). This specification does, however,
not aim to target this issue, if I understand the document correctly.

> 
>> * to have enough information to decide whether I want to implement
>> this specification.
> 
> If you have the memory at the message initiator (per peer storage,
> about 4 bytes needed per peer plus the space needed to identify that
> peer) and the space for a few additional lines of code, you want to
> implement this specification. (Note that you always can fall back to
> basic CC if the per-peer storage space runs out.)

I think it would be point this out in the specification in the form of
"here is the cost of the mechanism".

> There are, but we haven’t spent time on creating WG consensus about

The document hasn't seen a lot of input from the working group at all.
I would say that this is not surprising since the necessary expertise is
certainly not in CORE. Do you see this as a problem?

> 
>> I also believe that many readers are worried that the enhancements
>> to CoAP over UDP quickly turn into CoAP over TCP.
> 
> Moving to TCP is a completely different class of complexity (several
> orders of magnitude more than just adding CoCoA).

Is that really the case? When I read
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-00
then I get a different impression. In my review of that document I have
asked the authors of th
draft-ietf-lwig-tcp-constrained-node-networks-00 to provide some of that
data.

Ciao
Hannes

PS: The draft should discuss the difference between the weak and the
strong estimator early in the draft (rather than using the terms and
only in Section 4.2.2 mentioning the motivation). I would also feel
better if this idea of weak and strong estimator is reviewed and agreed
by the transport area directorate since it is in contradiction to what
is said in RFC 8085.

The text in Section 5 "Advanced CoAP Congestion Control:
Non-Confirmables" essentially comes without motivation. The same is true
for the algorithm in Appendix A. Are you expecting that the algorithm in
Appendix A will stay in the draft given that "The mechanism defined in
this appendix has received less research" as the authors correctly point
out?

There are also two reference sections, which is unusual.