idnits 2.17.1 draft-bormann-core-cc-qq-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational March 09, 2015 5 Expires: September 10, 2015 7 Qualifying Questions for a CoAP Advanced Congestion Control Scheme 8 draft-bormann-core-cc-qq-01 10 Abstract 12 CoAP (RFC7252) comes with a conservative base congestion control 13 scheme. Advanced congestion control schemes can be defined where 14 better performance is desired for a certain area of application. 16 This document is a strawman for a set of questions that could be used 17 in qualifying a CoAP advanced congestion control scheme. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 10, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Area of application . . . . . . . . . . . . . . . . . . . . . 2 55 3. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Stability . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 8. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9. Concurrent traffic . . . . . . . . . . . . . . . . . . . . . 5 62 10. Evaluation quality . . . . . . . . . . . . . . . . . . . . . 5 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 12. Security considerations . . . . . . . . . . . . . . . . . . . 5 65 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 14.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 14.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 (See abstract.) 75 This document should be read in conjunction with more fundamental 76 documents such as [RFC2914], [RFC5405]. 78 The set of questions posed here cannot be deemed to be a set of 79 acceptance criteria. The questions are broad enough that it is 80 unlikely good research will be available to answer each and every 81 single facet of them. 83 (The set of questions in the current version of the document is 84 clearly just a start; this version is being published to elicit 85 contributions.) 87 2. Area of application 89 Q(1) Is the algorithm meant for general use? If not, can the scope/ 90 area of application be defined in an unambiguous way? This is 91 particularly important if some of the below questions only can 92 be answered in a positive way for that area of application. 94 3. Protection 96 Q(2) Does this scheme really protect the network? 98 Answering this question requires realistic simulations (see 99 Section 10). Generally, a single set of simulations should 100 vary a parameter such as offered load, number of clients etc. 102 "Protecting the network" is not easily defined. Comparing the 103 behavior to that of base CoAP ([RFC7252], Section 4.7) is an 104 acceptable proxy. Indicators that might be evaluated include: 106 * Number of retries (or the related metric: energy per 107 delivered bit) 109 * Number of spurious retransmissions 111 * Goodput/throughput ratio (average, burst) 113 * Settling time (e.g., reaction time to and recovery after a 114 burst) 116 Q(3) Does the protection rely on the self-protection of the 117 underlying network? If that can be switched off, does the 118 scheme still protect the network? 120 (Anecdote: An early version of CoCoA turned out to work well 121 only as long as it was run over a MAC with exponential 122 backoff.) 124 4. Stability 126 Beyond congestion collapse, there are other situations that a 127 congestion control algorithm should try to avoid. 129 Q(4) Are synchronization effects expected in CORE environments (also 130 see granularity statement below); i.e., if an application tries 131 to deliver an exchange at a predetermined point of time (i.e. 132 temperature reading every 5 min), all stacks might 133 "synchronize" into colliding with each other, and backing off 134 in a lock-step fashion. That might result in unreasonably 135 large RTOs in significant parts of the population of sensors; 136 It might be good to have the binary backoff combined with some 137 kind of dithering/randomization, in order to break such sync 138 early on? 140 Q(5) What is the expected (required, desirable) granularity of the 141 RTT measurements? For an algorithm that has all the intervals 142 specified in seconds, an implementer not aware of this issue 143 might choose a granularity of a second. If that is not 144 intended, or RTT timer granularity should be a certain 145 resolution (i.e. in the same order of magnitude of the lowest 146 expected RTT), a hint on that might be good. 148 Q(6) What is the expectation of the algorithm on the stability of 149 the parameters of the network? How long is a history of 150 measured RTTs expected to be useful in predicting the future? 152 Q(7) If any mechanisms are adopted from other congestion control 153 algorithms, what analysis has been undertaken to avoid known 154 problems of those mechanisms (e.g., [RFC6298] will increase RTO 155 when RTT decreases). 157 5. Scalability 159 Q(8) Do we have numbers for larger networks? 161 CoAP applications are expected to be run in networks with thousands 162 of nodes (and even many more). At least some of the qualifying 163 questions (and in particular protection) should be examined up to 164 such a scale. 166 6. Range 168 Q(9) What is the range of parameters the scheme is supposed to 169 cover? 171 Congestion control schemes need to adapt to a large range in each of 172 the governing parameters such as latency, loss, and offered load. 173 What do we know about the range actually being covered? (Note that 174 it is quite acceptable for a scheme not to "use" the full range, 175 e.g., not to be able to exploit very short latencies for improved 176 performance.) 178 7. Scope 180 Q(10) What is the scope of a single instance of the algorithm? 181 (E.g., a five-tuple, a host pair, a single host and an IP 182 address prefix with many peers?) 184 Q(11) What is done to control the aggregate congestion behavior (cf. 185 [RFC5405] section 3.1)? 187 8. Performance 189 Q(12) Is it worth it? 191 While improved performance certainly is not part of the acceptance 192 criteria, deployers are unlikely to switch on a scheme that is worse 193 than the default one. 195 Metrics might include goodput, latency (average, median, 95th 196 percentile, etc.), goodput/throughput ratio, ... Again, these are 197 best presented over a scale varying some input parameter. 199 9. Concurrent traffic 201 While TCP fairness is both overrated and almost trivially achieved 202 for what is basically a lockstep protocol, some information is 203 desirable on how the scheme fares with concurrent traffic (such as 204 base CoAP, TCP, or even inelastic UDP flows). 206 Q(13) Does the scheme starve? 208 Q(14) Does it do significant damage to the control algorithms of the 209 concurrent traffic? 211 10. Evaluation quality 213 Of course, for all simulations and experiments, we need to know more 214 about the models and environments used. Ideally, the evaluation 215 would not fail the criteria in [incredibles]. 217 11. IANA Considerations 219 This document makes no requirements on IANA. (This section to be 220 removed by RFC editor.) 222 12. Security considerations 224 The security considerations of [RFC2914] apply. 226 Q(15) Does the scheme have any special security considerations beyond 227 those intrinsic to congestion control? 229 13. Acknowledgments 231 The development of this document was spurred by the questions asked 232 at the IETF90 CoRE WG session on congestion control, in particular 233 those by Lars Eggert and Richard Scheffenegger (who also supplied 234 most of the text for section Section 4). It is also based on the 235 experience in CoCoA evaluation by August Betzler, Carles Gomez, Ilker 236 Demirkol, Josep Paradells, Matthias Kovatsch. 238 14. References 240 14.1. Normative References 242 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 243 Application Protocol (CoAP)", RFC 7252, June 2014. 245 14.2. Informative References 247 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 248 2914, September 2000. 250 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 251 for Application Designers", BCP 145, RFC 5405, November 252 2008. 254 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 255 "Computing TCP's Retransmission Timer", RFC 6298, June 256 2011. 258 [incredibles] 259 Kurkowski, S., Camp, T., and M. Colagrosso, "MANET 260 simulation studies: the incredibles", SIGMOBILE Mob. 261 Comput. Commun. Rev. 9(4) p. 50-61, DOI: 262 10.1145/1096166.1096174, 2005. 264 Author's Address 266 Carsten Bormann 267 Universitaet Bremen TZI 268 Postfach 330440 269 Bremen D-28359 270 Germany 272 Phone: +49-421-218-63921 273 Email: cabo@tzi.org