Minutes interim-2017-lpwan-13: Tue 17:00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2017-lpwan-13: Tue 17:00
State Active
Other versions plain text
Last updated 2017-12-19

Meeting Minutes

Connection details

*    Date: December 19th 2017
*    Time: 8-9AM DST, 17:00 CEST:
*    Webex Link:
*    Meeting number: 204 648 433

*    Meeting password: 62YbPWpj (62927975 from phones)
*    Join from a video conferencing system or application
*    Dial 204648433@cisco.webex.com
*    Join by phone
*    +1-866-432-9903 Call-in toll-free number (US/Canada)
*    +1-408-525-6800 Call-in toll number (US/Canada)
*    Access code: 204 648 433
*    Global call-in numbers:


*    [17:05] Administrivia                                           [05min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts (WGLC / forthcoming WGLC)

*    [17:10] SCHC MIC selection                                      [25min]
*    [17:35] SCHC update and Discussion: WGLC ready or not ready     [20min]
*    [18:00] AOB                                                     [05min]

Minute takers

*    Ana Minaburo
*    Pascal Thubert
*    Dominique Barthel

*    Pascal Thubert
*    Alex Pelov
*    Laurent Toutain
*    Ana Minaburo
*    Felipe Díaz-Sánchez
*    Dominique Barthel
*    Juan-Carlos Zuniga
*    Julien Catalano

Past Attendees

*    Alex Pelov
*    Ana minaburo
*    Dominique Barthel
*    Laurent Toutain
*    Carles Gomez
*    Ivaylo Petrov
*    Juan-Carlos Zuniga
*    Julien Catalano
*    Orne Brocaar
*    Pascal Thubert
*    Vijay Gharge
*    Orne Brocaar
*    Paventhan Arumugam
*    Paul Duffy

Action Items from last time

* Update SCHC draft


 [17:05] Administrivia                                           [05min]
    o    Note-Well, Scribes, Agenda Bashing

        * Pascal: IETF meeting, taking minutes.

    o    Status of drafts (WGLC / forthcoming WGLC)

    * Pascal: two presentation to finish the work on SCHC
    * Last call was deferred waiting for the MIC resolution

   [17:10] SCHC MIC selection                                      [25min]
   * Laurent: I made some simulation on CRC to detect fragment loses during the
   transmission. * Detect error and eliminate UDP checksum to have a good
   compression * Use 16 CRC but is not efficient or CRC32 that takes more place
   that may take 2 bytes as UDP checksum
  * describes simulation setting: random data (uniform), exhaustive list of
  possible fragment losses. * computes CRC with fragment loss, if identical to
  CRC without fragment loss then it's a mis-detection problem.
   * Juan Carlos: do you cnisider burst errors? You mentionned tat you tested
   combinatio , which? * Laurent: I tests all the losses without any
   distribution, all the combinations not related to a pattern *Dominique: the
   error model is that a fragment is present on the receive side or not ? 
   Laurent: yes. * Laurent: could argue that successive fragments are more
   likely to be lost together than remote fragments. * Laurent: I did not study
   lost packets only error in all the received packets * Laurent: I only take
   16 fragment as a max number, I don't think we will use larger FCN number *
   describes simulation results. With CRC16 and 20 fragments, about 15
   mis-detection cases across the 2ˆ20 possible cases. * Dominique: 5 missing
   fragments is likely so the chances of getting a false positive (good CRC for
   a wrong packet) exist in practice * trying out different CRCs. Similar
   strength.  Tried MD5 hash as well, used first 2 bytes as MIC. Works equally
   well. * with CRC32, no mis-detection. Nor with 3 (or 4?) bytes of MD5. *
   more work needed on this. * conclusion: CRC16 not good when more than 8
   frags. CRC32 is perfect, but needs 2 more bytes, so could send length
   instead and keep CRC16. * proposed options: include length and do not
   compress UDP checksu; mandate CRC32c; mandate CRC that fits the number of
   fragments; use CRC16 and live with mis-detections. Anyway, this would be a
   recommendation, that can be overridden by the SCHC-over-foo document.

   * JCZ: A good conclusion is using CRC16 to protect less than 8 number of
   fragments * JCZ: But if we need a one single method to support for the
   general solution can be CRC16 * Pascal: It is also good to define the
   correct CRC in the foo documents. * Pascal : fragmentation is very specific
   to the technology, more than * Pascal: use SHOULDs, let SCHCover-foo
   override this. * JCZ: we want a baseline behavior in this doc. The MUSTs
   must be in the SCHC-over-foo doc. * Pascal: this doc should say "at least as
   good as CRC16" because of UDP. * Pascal: CRC32c seems beyond the need. Do we
   stick with CRC16 or add the Length field? * Laurent: if we transmit a number
   of fragments, cannot change size of fragments during transmission. * Pascal:
   thought we had made a decision not to change the fragment size during
   transmission of packet. * Pascal: think we said we would use MIC instead of
   length for that very reason: change the fragment size on the fly. * JCZ: *
   Pascal: number of fragments and CRC. * Laurent: CRC24 could be good. Not
   trie, but tried 3 bytes of MD5. * Laurent: could take the risk of CRC16. *
   Laurent: in the proposed solution, we dont use the fact that fragment are
   lost, not bits. With good code theory, we could do better with 4 bytes, or
   same on 3 bytes only.
 [17:35] SCHC update and Discussion: WGLC ready or not ready     [20min]
   * Ana: -v8 issued. Some inputs by Carsten today.
   * added intro to fragmentation, added fragmentation terminology in the
   terminology section. * asks the audience opinion about swapping the two
   sections 5.2 and 5.3 * Pascal: usually frame formats before behavior. * Ana:
   regarding Abort frames. Distinct Abort frames for sender and receiver. Both
   ends should abort in either case. Do we want to ACK aborts or not? *
   Laurent: forgot what was decided in Singapore (if anything), but today think
   we should not ack an abort. * Laurent: and now, we also have a timer. * Ana:
   make decision now that Abort is not acked. Because we have timers
   everywhere. * Ana: * Laurent: will complete study on CRC by end of week. *
   Pascal: will launch WGLC end of week. For how long? Can reviewers read by
   Jan 16th? * Pascal: will launch WGLC ending on Jan 16th.

[18:00] AOB                                                     [ 0min]