Minutes interim-2018-lpwan-02: Tue 17:00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2018-lpwan-02: Tue 17:00
State Active
Other versions plain text
Last updated 2018-01-31

Meeting Minutes

   Connection details

*    Date: January 30, 2018
*    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                                           [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

*    Dominique Barthel


*    Pascal Thubert
*    Alex Pelov
*    Laurent Toutain
*    Ana Minaburo
*    Vanessa Valderrama
*    Dominique Barthel
*    Edgar Ramos
*    Carles Gomez
*    J Sanchez
*    Ramon Sanchez
*    Juan-Carlos Zuniga
*    Felipe Díaz-Sánchez

Action Items from last time

* Juan Carlos Review



*    [17:05] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing
         Since last meeting :
             two more reviews received (Dominique, Edgar),
             expecting one by Juan Carlos tonight
    o    Status of drafts

*    [17:08] SCHC WGLC                                               [30min]
     Ana: gives the ball to Carles
     Carles: processing the last round of reviews. No slide at this time
     could use this time to discuss the most prominent/general/technical
     comments (as opposed to editorial). or complete presentation left over
     from last interim? Alex: pick the main ones (among the non-editorial).
     Ana: opened some tickets. Automatic notification mails not working. 11
     open tickets right now. #6: fully-used All-0 or All-1 window. Laurent:
     when full window cannot be sent. In ACK-on-error, device knows this
     limitation, so knows when to ACK or not. Ana: propose to use this for
     ACK-always. No objection #2: default value for Hop limit? no default.
     Because we assume the LPWAN has no loop, Hop limit is of no use. In a
     topology with risk of loop, field should be sent (potentially on fewer
     bits). #8: possible to have different Rule IDs with same DTAG? DTAG is for
     fragmentation. Laurent: Rule ID defines processing, DTAG defines packet
     that is being fragmented. Dominique: If Rule ID describes fragments vs.
     ACKs, then you can litterally have different Rule IDs with the same DTAG.
     Was that the question? #9: Laurent: protocol is flexible enough to support
     reordering between RGW and NGW. Dominique was to check the situation with
     LoRaWAN. Edgar: comment that re-ordering should not happen between RGW and
     NGW is not needed. Works anyway. JCZ: most of my comments on clarification
     of the architecture definition. Suggest keeping the text assuming a star
     topology, just to avoid opening a can of worms. Ana: packet duplpication
     as already discussed when reviewing the state machine. The state machine
     drops duplicate packets. Edgar: this was the fragmetnation state machines.
     How about compression state machines? Edgar: commetn was mainly about
     possiblity that tje decomporessor would receive twice the same packet,
     amybe even once fragmented adn once not fargmented. Laurent: not our
     problem. Compressor will still work Edgar: looking at making this future
     proof if we go beyond star topology. Laurent: forwarding capability works.
     But we don't want routing protocol, etc. Laurent: we can start with this,
     and if we see a need/problem we'll write another document. Carles:
     re-ordering prblem in ACL-always, last windows compreises several
     fragmetns, 6,5, 4, 7. If 7 arrives frist at receiver, does the mechanism
     still work ? In ACK-always, bleive yes, albeit less eficiently. Laurent:
     the last window now behaves the same in ACK-always and ACK-on-error.
     <<< sorry I was interrupted, missed a minute or so of the
     meeting. Please help filling in the blank >>>> Pascal: thought
     we hasd a corner case in the last window. Are you sure it works? JCZ:
     referring to the reason why we put the MIC? Pascal: no, MIC is much older.
     Discussion at the last interim. Don't remember. Edgar: Laurent: "out of
     sequence" instead of "re-ordering". Carles: "assume that out of sequence
     will not happen". Pascal: even if rare, if it happens, we accept it. Did
     not do my review with this assumptation. If we say re-ordering is
     possible, need to redo the review with this assumption in mind. Edgar:
     Laurent: could we keep a "no re-ordering assumed"in the SCHC document, and
     in the technology dcument "after frther examination, a reordering of so
     much is acceptable". #11 padding in ACK? Laurent Edgar: comment about the
     whole padding thing. NB-IOT does not need byte alignement of the payload.
     There is padding a Layer 2 anyway. Does padding need to be here, or should
     be left to the technology dcument? JCZ: agree to remove it from the
     general SCHC document, and leave it to the technology documents. Ana:
     several months ago, decided that padding was best put at the end. Edgar:
     padding here is to achieve byte alignement. Also filling a transport
     block. leave the latter to the L2. The former may not be needed on some
     technologies. Carles: the SCHC doc could mention the two options (padding
     between header and payload or at the end). Leave to the tech document to
     select. Edgar: rather have only one specified, and activate it or not.
     Otherwise interop will be hard, especially multi-RAT networks. Laurent: in
     LoRa, we (Acklio?) use the FPort byte to carry the Rule ID, in one full
     byte. Some form of padding! Laurent: Ana: suggests to have a DEFAULT
     specification in the SCHC document, and leave it to the technology
     document to specify differently if it wants! #10 interleaving possible
     between fragmented and non-fragmented packets? yes. Rewriting of text?
     JCZ: interleaving of different fragmented packets? Laurent: yes, they have
     different DTAGs. Edgar: will see devices multi-RAT. Also, on NB-IoT,
     several bearers of different characteristics. Fragmentation might be
     needed on one bearer and not on another one. Are the instances of
     compressor/decompressor one per radio access or one per bearer? Carles:
     for compression, rules could be the same even cross different radios.
     Fragmentation need to be specific. JCZ: Laurent: the current description
     only aapplies to a single bearer. Edgar: you mean one entity per Laurent:
     current description is for a single radio. could extend model e.g. with
     different rules for different bearers. Pascal: this goes beyond to initial
     goal. Edgar: would avoid this spec to be limiting us in the fture. Pascal:
     can be made to work with a set of rule per bearer. Edgar: LTE-M is a bit
     more dynamic, switching from one bearer to another. Fear that this
     approach might be a limitation. Maybe as JCZ says, compressed could be
     same, fragmentation changed  when changing bearer. Pascal: same with
     LoRaWAN. Cannot switch SF in the middle of a fragmented packed. Esgar:
     similar, even worse with LTE-M. Pascal: changing MTU, IP above it should
     know. Edgar: maybe you're right, hae to have a maximum MTU. Pascal: based
     on this discussion, start closing some ticket. Ana: will open a new set
     with Edgard's and Dominique's comments. Pascal: Edgar, keep us updated on
     NB-IoT's constraints and characteristics.
[18:03] meeting conludes
*    [17:xx] CoAP SCHC                                               [15min]
*    [17:55] AOB                                                     [ 5min]