CoRE Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Informational March 09, 2015 Expires: September 10, 2015 Qualifying Questions for a CoAP Advanced Congestion Control Scheme draft-bormann-core-cc-qq-01 Abstract CoAP (RFC7252) comes with a conservative base congestion control scheme. Advanced congestion control schemes can be defined where better performance is desired for a certain area of application. This document is a strawman for a set of questions that could be used in qualifying a CoAP advanced congestion control scheme. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bormann Expires September 10, 2015 [Page 1]
Internet-Draft CC: Qualifying Questions March 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Area of application . . . . . . . . . . . . . . . . . . . . . 2 3. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Stability . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Concurrent traffic . . . . . . . . . . . . . . . . . . . . . 5 10. Evaluation quality . . . . . . . . . . . . . . . . . . . . . 5 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 12. Security considerations . . . . . . . . . . . . . . . . . . . 5 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 14.1. Normative References . . . . . . . . . . . . . . . . . . 6 14.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction (See abstract.) This document should be read in conjunction with more fundamental documents such as [RFC2914], [RFC5405]. The set of questions posed here cannot be deemed to be a set of acceptance criteria. The questions are broad enough that it is unlikely good research will be available to answer each and every single facet of them. (The set of questions in the current version of the document is clearly just a start; this version is being published to elicit contributions.) 2. Area of application Q(1) Is the algorithm meant for general use? If not, can the scope/ area of application be defined in an unambiguous way? This is particularly important if some of the below questions only can be answered in a positive way for that area of application. Bormann Expires September 10, 2015 [Page 2]
Internet-Draft CC: Qualifying Questions March 2015 3. Protection Q(2) Does this scheme really protect the network? Answering this question requires realistic simulations (see Section 10). Generally, a single set of simulations should vary a parameter such as offered load, number of clients etc. "Protecting the network" is not easily defined. Comparing the behavior to that of base CoAP ([RFC7252], Section 4.7) is an acceptable proxy. Indicators that might be evaluated include: * Number of retries (or the related metric: energy per delivered bit) * Number of spurious retransmissions * Goodput/throughput ratio (average, burst) * Settling time (e.g., reaction time to and recovery after a burst) Q(3) Does the protection rely on the self-protection of the underlying network? If that can be switched off, does the scheme still protect the network? (Anecdote: An early version of CoCoA turned out to work well only as long as it was run over a MAC with exponential backoff.) 4. Stability Beyond congestion collapse, there are other situations that a congestion control algorithm should try to avoid. Q(4) Are synchronization effects expected in CORE environments (also see granularity statement below); i.e., if an application tries to deliver an exchange at a predetermined point of time (i.e. temperature reading every 5 min), all stacks might "synchronize" into colliding with each other, and backing off in a lock-step fashion. That might result in unreasonably large RTOs in significant parts of the population of sensors; It might be good to have the binary backoff combined with some kind of dithering/randomization, in order to break such sync early on? Q(5) What is the expected (required, desirable) granularity of the RTT measurements? For an algorithm that has all the intervals Bormann Expires September 10, 2015 [Page 3]
Internet-Draft CC: Qualifying Questions March 2015 specified in seconds, an implementer not aware of this issue might choose a granularity of a second. If that is not intended, or RTT timer granularity should be a certain resolution (i.e. in the same order of magnitude of the lowest expected RTT), a hint on that might be good. Q(6) What is the expectation of the algorithm on the stability of the parameters of the network? How long is a history of measured RTTs expected to be useful in predicting the future? Q(7) If any mechanisms are adopted from other congestion control algorithms, what analysis has been undertaken to avoid known problems of those mechanisms (e.g., [RFC6298] will increase RTO when RTT decreases). 5. Scalability Q(8) Do we have numbers for larger networks? CoAP applications are expected to be run in networks with thousands of nodes (and even many more). At least some of the qualifying questions (and in particular protection) should be examined up to such a scale. 6. Range Q(9) What is the range of parameters the scheme is supposed to cover? Congestion control schemes need to adapt to a large range in each of the governing parameters such as latency, loss, and offered load. What do we know about the range actually being covered? (Note that it is quite acceptable for a scheme not to "use" the full range, e.g., not to be able to exploit very short latencies for improved performance.) 7. Scope Q(10) What is the scope of a single instance of the algorithm? (E.g., a five-tuple, a host pair, a single host and an IP address prefix with many peers?) Q(11) What is done to control the aggregate congestion behavior (cf. [RFC5405] section 3.1)? Bormann Expires September 10, 2015 [Page 4]
Internet-Draft CC: Qualifying Questions March 2015 8. Performance Q(12) Is it worth it? While improved performance certainly is not part of the acceptance criteria, deployers are unlikely to switch on a scheme that is worse than the default one. Metrics might include goodput, latency (average, median, 95th percentile, etc.), goodput/throughput ratio, ... Again, these are best presented over a scale varying some input parameter. 9. Concurrent traffic While TCP fairness is both overrated and almost trivially achieved for what is basically a lockstep protocol, some information is desirable on how the scheme fares with concurrent traffic (such as base CoAP, TCP, or even inelastic UDP flows). Q(13) Does the scheme starve? Q(14) Does it do significant damage to the control algorithms of the concurrent traffic? 10. Evaluation quality Of course, for all simulations and experiments, we need to know more about the models and environments used. Ideally, the evaluation would not fail the criteria in [incredibles]. 11. IANA Considerations This document makes no requirements on IANA. (This section to be removed by RFC editor.) 12. Security considerations The security considerations of [RFC2914] apply. Q(15) Does the scheme have any special security considerations beyond those intrinsic to congestion control? 13. Acknowledgments The development of this document was spurred by the questions asked at the IETF90 CoRE WG session on congestion control, in particular those by Lars Eggert and Richard Scheffenegger (who also supplied most of the text for section Section 4). It is also based on the Bormann Expires September 10, 2015 [Page 5]
Internet-Draft CC: Qualifying Questions March 2015 experience in CoCoA evaluation by August Betzler, Carles Gomez, Ilker Demirkol, Josep Paradells, Matthias Kovatsch. 14. References 14.1. Normative References [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. 14.2. Informative References [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011. [incredibles] Kurkowski, S., Camp, T., and M. Colagrosso, "MANET simulation studies: the incredibles", SIGMOBILE Mob. Comput. Commun. Rev. 9(4) p. 50-61, DOI: 10.1145/1096166.1096174, 2005. Author's Address Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Bormann Expires September 10, 2015 [Page 6]