1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 130913_webex

View History

Minutes Webex 13 September 2013, 6TiSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Dominique Barthel
  3. Thomas Watteyne

Present (alphabetically)

  1. Thomas Watteyne
  2. Pascal Thubert
  3. Alaeddine Weslati
  4. Cedric Adjih
  5. Diego Dujovne
  6. Dominique Barthel
  7. Geraldine Texier
  8. Maria Rita Palattella
  9. Pouria Zand
  10. Qin Wang
  11. Raghuram Sudhaakar
  12. Tom Phinney
  13. Xavi Vilajosana

Recording

Slides

Action Items

  • Xavi to send to ML (1) the list criteria currently defined on CoAP observe pattern and (2) whether it is possible to extend this list.
  • Thomas to send list of CoAP elements that can be used in 6TiSCH to ML.
  • Thomas to confirm rough consensus about "Can CoAP be used to transport 6TiSCH signaling traffic" on ML.
  • Thomas to confirm rough consensus on "RPL OF0 parameters" on ML.
  • Pouria to present WirelessHART and and ISA100.11a equivalent formats for "report flow" at next week's call.

Agenda

Minutes

  • [08.05] Meeting starts
  • [08.07] Administrivia
    • Approval minutes last call

      No issues raised. Minutes approved.

    • Approval agenda

      No issues raised. Agenda approved.

  • [08.08] Chartering process
    • Review process:
      • Dashboard
      • Ballot
      • History
      • Great feedback during "Internal Review" state.
      • Some back-and-forth between members of IESG and Pascal/Thomas. Triggered some rewording of the charter (see below).
      • State changed to External review from Internal review.
    • Updates to charter text
  • [08.13] CoAP [30min]
    • presentation
      • CoAP overview: [Raghuram]
        • Carsten is one of the authors of CoAP.
        • Can be described a "HTTP for Low Power Lossy devices"
        • Analogous to HTTP. Follows REST architecture.
        • CoAP brings the REST features to the LLN domain.
        • Designed for minimal payload size.
        • Includes options relevant to the LLN domain.
        • On top of UDP.
        • Defines messaging architecture.
        • Defines request/response formats.
        • Supports identification of resources through URIs.
        • Publish/subscribe features (different from HTTP)
        • 4 types of messages:
          • CON: confirmable (reliable)
          • NON: non-confirmable (unreliable)
          • ACK: acknowledgement
          • RST: reset
        • With CoAP, we can achieve reliable content delivery/request
        • Two identifiers:
          • Message ID: match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable
          • Token: used to correlate requests and responses
        • These two identifiers allow different models:
          • piggy-backing, where response is payload of ACK
          • asynchronous, where response comes on its own, possibly after the ACK.
        • 4 Basic Methods: GET/PUT/POST/DELETE
        • Multiple Respsnse categories (similar to HTTP):
          • 2xx
          • 4xx
          • 5xx
        • Options and URIS.
          • Identification of resources
          • Representation of the resource
            • Content-format: defines the type of the content, e.g, text, uint16, etc.
        • Conditional options.
          • matching options to identify specific resources
          • age for caching, etc.
        • URI Scheme:
          • Options are the containers of the parameters (uri).
          • Notion of URI in http.
          • Size of names in the URI affect size of options so this is recommended to be minimal.
          • Does not define the max size of the payload. recommend to have it smaller than PDU.
        • CoAP other topics:
          • Security using DTLS
          • DICE
          • Service Discovery
          • Proxying - reverse proxies/ relay proxies.
          • Caching - Max age
      • Observe feature in CoAP: [Xavi]
        • The purpose is to stay aware of the updates of the state of the resource. Don't want to actively poll all the time.
        • Interested node registers to a resource, and will be pushed data from the server.
        • The observer sends a GET request to the server. The server responds with the current state of resource, and adds the client to the list of observers.
        • "Observe" is an option of the GET method and response.
        • In the response, the "Observe" option identifies the notification with a 24-bit integer value.
        • This value increments between notifications, and is used to order the data received.
        • The observe option does not have anything to do with the query that is done. So it seems that the GET can contain Content-Match fields to make it conditional. That is, if observe header is there, then this will be notified upon server side changes on the resource (applying condition).
        • [Dominique] How can a client know that the server is able to add the client to the list of listeners?
        • draft-core-observe states:

          The Observe Option is not critical for processing the request. If the server is unwilling or unable to add the client to the list of observers of the target resource, then the request falls back to a normal GET request.

        • [Qin] What kind of criteria can be used in the observe pattern? That is, can the client somehow specify "exotic" criterie (e.g. "send this metric when I have only one routing parent") design the criteria to get a notification?

          Action item: Xavi to send to ML (1) the list criteria currently defined on CoAP observe pattern and (2) whether it is possible to extend this list.

      • discussion > Action item: Thomas to send list of CoAP elements that can be used in 6TiSCH to ML.
        • Next step: continue with CoAP payload discussion. CBOR??
      • Call for rough consensus on using CoAP in 6TiSCH:

        No issue raised. Rough consensus on the call. Action item: Thomas to confirm rough consensus on "CoAP can be used to transport 6TiSCH signalling traffic" on ML.

  • [08.55] Rank rounding error, churn and hysteresis
    • Context and overview discussion
      • RPL has a mechanism for loop avoidance.
      • RPL OF0 - rank is a 2 byte value.
      • Several factors are used to compute the OF0.
      • minHopRankIncrease -> makes integer part be a monotonically increasing byte
      • DAGRank(rank) is a function indicative of the rank of a node.
      • How do we propose changes/hints to the computation of the ETX.
    • Call for rough consensus on use OF0 as described in http://www.ietf.org/mail-archive/web/6tsch/current/msg01247.html.

      No issue raised. Rough consensus on the call. Action item: Thomas to confirm rough consensus on "RPL OF0 parameters" on ML.

    • discussion on hysteresis
      • RFC6719

        Running out of time. Moved to next week's call.

  • [09.09] AOB
    • Presenting WirelessHART and and ISA100.11a equivalent formats next call?

      Action item: Pouria to present WirelessHART and and ISA100.11a equivalent formats for "report flow" at next week's call.

    • Any other business?

      No other business raised.

  • [09.08] Meeting ends

Updated