Internet DRAFT - draft-bormann-core-cc-qq

draft-bormann-core-cc-qq







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]