Hi Carsten,
thanks for the quick response.
Post by Carsten BormannThe 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.
Post by Carsten BormannPost by Hannes Tschofenig* 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".
Post by Carsten BormannPost by Hannes TschofenigAre there answers to these questions?
There are, but we haven’t spent time on creating WG consensus about these answers.
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?
Post by Carsten BormannPost by Hannes TschofenigI 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.