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

[Carsten Bormann <[e-mail]>]

Hi Hannes,

> On Sep 2, 2017, at 20:22, Hannes Tschofenig <[e-mail]> wrote:
> 
> 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.

Thank you; this is very useful input.

> One of the most important sections of a document, the introduction
> 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
> * to learn what the perceived problem is, and

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
> 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.)

> Are there answers to these questions?

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

> 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 agree that we shouldn’t be relying on expired I-Ds.

> 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).

> 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?

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