Minutes interim-2018-lpwan-01: Tue 17:00
minutes-interim-2018-lpwan-01-201801161700-00

Connection details
------------------

*    Date: January 16, 2018
*    Time: 8-9AM DST, 17:00 CEST:
https://www.worldtimebuddy.com/?qm=1&lid=2988507,1816670,5391959,5128581&h=2988507&date=2018-01-16&sln=17-18
*    Webex Link: :
https://cisco.webex.com/cisco/j.php?MTID=m016ded95875427897fd1089cb921b30bbPWpj
*    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:
*   
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=410481357&tollFree=1

Agenda
------

*    [17:05] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts

*    [17:15] SCHC WGLC                                               [30min]
*    [17:45] CoAP SCHC                                               [15min]
*    [17:55] AOB                                                     [ 5min]

Minute takers
-------------

*    Ana Minaburo
*    Pascal Thubert
*    Dominique Barthel
*    Diego Dujovne

Attendees
---------

*    Pascal Thubert
*    Alex Pelov
*    Laurent Toutain
*    Ana Minaburo
*    Diego Dujovne
*    Dominique Barthel
*    Julien Catalano
*    Edgar Ramos
*    Carles Gomez
*    Ivaylo Petrov
*    Juan-Carlos Zuniga
*    Felipe Díaz-Sánchez
*    Vincent Audebert

Past Attendees
---------

*    Alex Pelov
*    Felipe Díaz-Sánchez
*    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
* Review from Dominique Barthel, Edgar Ramos, and Juan-Carlos Zuniga for
January 23

Minutes
-------

*    [17:05] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing
        * Alex presents the usual introduction
        * items to be added to the agenda? None. Agenda approved.
        * comments on the minutes of last meeting? None heard. Minutes are
        approved. * last meeting actions items: MIC discussion and SCHC WGLC.
        Both took place and will be discussed today.
    o    Status of drafts

*    [17:15] SCHC WGLC                                               [30min]
Edgar, JC and Dominique will provide reviews in the next couple of days. By end
of week probably, early next week at the latest. Pascal: the call will continue
until the 23rd. We have February to solve the issues. Ana: thanks all the
reviewers. Discuss today the items coming from reviews received in the mailing
list. Review from Steven:
    - zip bomb: does not seem to be possible. We know what we are doing. Agree
    to put the suggested comment into the document. LT: a risk of staturating
    the link with variable length fields - suggested DNS look-up so that device
    send name instead of address. Ana: out of scope of this document, does the
    group agree? Pascal: Edgar: IP is stable even when movement, may be in
    roaming Pascal: if IP address of application server is changed, we need to
    download new rules in the device. Need to think about it. Laurent: this doc
    is about compression. Comparing bits. Not the way the context is installed.
    Pascal: should be in a new document. Add a sentence that say that the rule
    may be changed but it will be specified in another document
Review from Pascal:
    - simplify abstract: will do
    - default Rule ID size? size depends on the technology.
    Pascal: say at the begining that other documents will specify more specific
    behaviors. Pascal and Dominique: is Rule ID constrained by byte boundaries
    in any way? See Figure 16. Clearly state if it is or it isn't, early in the
    document. Edgar: depends on whether fragmentation is mandatory in all
    implementations. Carles: Figure 16 and 17 are example. Pascal: Figure 10.
    JCZ: clarify that Rule ID size is not constrained by alignment. Pascal:
    technology document will describe if Rule ID is constrained by alignment
    for a particular technology. Generic SCHC does not place such a constraint.
    - fragmentation and compression are described together in the architecture.
    Suggestion to have them decoupled. Fragmentation may be done at application
    server, etc. Pascal: Laurent: separate compression for CoAP and for
    UDP/IPv6. Can be bunched together later. Recommend to keep fragmentation
    and compression together. Edgar: Some technologies has multiple reception
    points, which means that the reconstruction of the packet (if fragmented)
    has to be done in a point after the combining of packets is done. This
    restricts the places where the fragmentation is placed. In practice, this
    might be very close or just same place where the decompresion happens. Ana:
    we can have a SCHC function in various places of the architecture. Each
    instance can do either one or both of fragmentation and compression. Alex:
    add a sentence in the doc? Pascal: curious that the doc need a lot of
    changing if SCHC is divided in compression and fragmentation Ana: It is in
    the document, but for now you always have SCHC and fragmentation together
    in the same place. Maybe in the future we can have them split into multiple
    places. Edgar: on first reading, had difficulty understanding the flow.
    What is supposed to happen, in what order? the doc goes back and forth
    between compression and fragmentation. Edgar: especially the compression
    section seems less clear on the flow, the mechanism. The connection between
    the two (frag and compr) is not clearly described either. Pascal: inherited
    from the 6LoWPAN mindset Ana shows a diagram with compressed packet
    followed by the fragmentation. Dominique: we need to come up with a name
    for the "SCHC packet". The text currently uses various circonlocutions for
    it. - Pascal: some sentences could be written in clearer English. Beleives
    that the intended meaning is what we want, but the way it is expressed
    might be misleading.

     Ana: The window does not have to be full,

     Pascal: in section 5.5: In the introduction "The FCN will be assigned
     sequentially in a decreasing order starting from 2^N-2".

     Ana: remnant from old text. Will be corrected.

     Pascal: challenges that Ack-on-error works if first FCN is not necessarily
     2^N-2

     Laurent: 2^N-2 is not mandatory. Can work without. Gives more freedom.
     Benefit is ???

     Pascal: creating new problem for Ack-on-error.

     Laurent: we recommend to use the whole window (i.e. FCN starting at 2^N-2)
     but we don't want to mandate it.

     Pascal: then write what is the price/risk if you don't.

     Carles: agree that for Ack-always, 2ˆN-2 is not mandatory.

    Alex: write recommendation.
    - non-reordering: Laurent states that the protocol can now deal with
    re-ordering. We originally had this statement about LPWAN networks not
    re-ordering packets but we can remove it. Carles: Also in no ack mode.
    Laurent: even if a few fragments arrive out of order, no problem. Pascal:
    Keep the text as it is. The current text is consistent. Reordering may
    create many weird cases. Don't try to be better than you need because there
    is an associated cost. We don't support out of order fragments. Dominique:
    Out of-order can happen between multiple gateways and the NS. The point is
    valid to know if current SCHC works in presence of re-ordering or not. We
    can limit reordering to a limited time. Pascal: connection times between
    gateways and NS are nothing. Dominique: some early gateways use 3G for
    backhaul. Can have up to one second of delay. So out-of-ordering could take
    place between a 3G gateway and a wired gateway. Julien: The LoRaWAN system
    is made to keep the frame order. The NS will put frames in order before
    delivering to the upper layer. Dominique: pretty sure I saw out of order
    packets in a LoRaWAN system but, thinking about it, it might have been on
    the wireless logger interface, maybe not on the data interface. Dominique:
    will check anyway with Orange experts whether OoO can happen on the data
    interface. Edgar: Got a bit confused from the previous discussion since
    assumed that LORA has the combining of the packet in the network gateway
    that connects multiple base stations, and according to the SCHC
    architecture drawing the SCHC functions are located after the network
    gateway, not between the network gateway and the base stations. Just
    wondering if then this wasn't intended like that.
[18:00] meeting ends

*    [17:45] CoAP SCHC                                               [15min]
not addressed for lack of time

*    [17:55] AOB                                                     [ 5min]
not addressed for lack of time