Minutes interim-2017-lpwan-02: Wed 16:00
minutes-interim-2017-lpwan-02-201705101600-01

Connection details
------------
*    Date: 7-8am US Pacific, 4pm CEST:
http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-05-10&sln=14-15
*    Webex Link:
https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746
*    Meeting number (access code): 203 453 401 *    Meeting password: chicalors
(24422567 from phones)

Agenda
------------
*    [7:00]Administrivia                                             [ 2min]
    o    Note-Well, Blue Sheets, Scribes, Agenda Bashing
    o    Approval minutes from last meeting
*    [7:02] LPWAN Overview  (Steve)                                  [ 5min]
*    [7:07] SCHC IP/UDP Compression (Laurent, Ana, Carles)           [40min]
*    [7:47] SCHC CoAP (Laurent)                                      [10min]
*    [7:47] AOB                                                      [ 3min]

Action Items
------------
* Alex:

Minute takers

    -------------

*    Ana minaburo
*    Pascal Thubert
*    Carsten Bormann
*    Juan-Carlos Zuniga

Attendees
---------
*    Alex Pelov [x]
*    Ana minaburo
*    Arunprabhu Kandasamy
*    Carles Gomez
*    Carsten Bormann [x]
*    Juan-Carlos Zuniga [x]
*    Laurent Toutain [x]
*    Pascal Thubert
*    Samian Kaur [x]
*    Uday Davuluru

Past Attendees (previous meeting, for cc)
---------
*    Stephen Farrell
*    Ana minaburo
*    Laurent Toutain
*    Alex Pelov
*    Julien Catalano
*    Sumankumar Panchal
*    Tomas Bolckmans
*    Carsten Bormann
*    Arunprabhu Kandasamy
*    Hannes Tschofenig
*    Carles Gomez
*    Uday Davuluru
*    Diego Dujovne
*    Juan-Carlos Zuniga
*    Paul Duffy
*    A Paventhan
*    Friedhelm Rodermund

Minutes
-------

*    [7:00]Administrivia                                             [ 2min]
    o    Note-Well, Blue Sheets, Scribes, Agenda Bashing  => Agenda approved
    o    Approval minutes from last meeting => Minutes approved
    o    Alex introdcuces the documents

    * No changes for agenda
    * Last minutes are approved
    * Remmind the charter actions and milestones
    * Action items from last meeting:
    Review IP/UDP draft from JC and DD
    - First Review from JC to Ana, most about confusing terms,
    - Missed Fragmentation, he has already done SCHC compression part
    inputs from JCZ is already incorporated version 3
    - JCZ will send out New comments for version 3 including the fragmentation
    part - draft CoAP: CB and MV - not yet done - AP: meeting in person at
    Prague may be 2hrs - LT: we will need 2hrs if we want to discuss the CoAP
    part

Action Items from last meeting
------------------------------
*    [7:02] LPWAN Overview  (Steve)                                  [ 5min]
    o    AP: Stephen cannot attend, Alex presenting
    o    Stephen will send revision by Friday, then WG to do review till May
    24th, LC ready version by May 30th o Review by working group next week;
    friday; o Ana: next step to confirm the consensus on the vocabulary;

*    [7:07] SCHC IP/UDP Compression (Laurent, Ana, Carles)           [40min]
    o Presentor:Ana
    o changes in schc version3: modifications from JCZ incorporated
    This modifications seems to bring clearty to the draft
    o waiting for consensus on end device vs device
    - Consensus is called it Dev to match acronym
    o Application sever is now App because there is not necessarily a server,
    to be confirmed -Consensus is called it App o Added W in NG -> NGW o
    Comment from JCZ was that the names could be confusion, Function vs.
    Action. Changing CDF to CDA. o JCZ: I asked people for feedback from
    external view about readability, thus suggested the changes, in particular
    for acronyms o JCZ: recommend using the term device, abbrev as Dev. Is that
    a good idea? o PT: +1; calling for consensus on that o CB: agreement. o AP:
    agrees with Dev; onem2m calls DA: o PT: Come with proposal and disucss in
    mailing list o LT: App is fine APP not as ùmuch since people may think it
    is an acronym as opposed to an Abbreviation; o PT: Agree; App, NGW, Dev. o
    AP: We need to advance on fragmentation, we have 25mn. o Carles now talks
    about fragmentation o CG: All changes were added in 03, thanks to everyone
    for the feedback o CG: for windoow mode, one bit is added (W bit) to avoid
    ambiguity, as a window flip flop. o Window is complemented to recognize
    which window is in used o Exmples for the ise of W:
        The retries will use the same W is used, with the same value

    o CB: repeating hi
    o PT do you want no window at all or do you want
    o CB: Not window at all, the struct of transmission of the single packet is
    modify, o PT: the window is to avoid ambiguity, the fragment counter is
    small in size of bits, so there is not enough to number all the fragments,
    o CB: confusion with the SN o PT:  If not trucking this is right but when
    trucking there is a sequence and we need to avoid ambiguity o CB: It is
    very expensive to do this o PT: The problem is the number of bits to
    number, so there is not enough so need a window, nd we need to eliminate
    the ambiguity o CB: More regular transmission than retransmission, it is
    more impotant to optimize regular ttransmission than retransmissions o PT:
    So we need more bits to renumber all this framents o AP: So the MTU is 11
    bytes, so we need more than 200 to numebr this fragments o CB: It is not
    necessary need a window o LT/ Well this is a mechanisms, what the ML think?
    it is a good solution about the reduction of bits, and it is reliable. What
    people want to implement and use? o AP: We need to see avout this question,
    CG find a solution about the previous question about drapping out, so this
    is solved o CB: RFC 3819, section 8 o CG: Next slides; identify as pending
    in the lo ast meetings but now is on o CG: Possible solution, with an
    ambiguity that can arrise, with twoo format for transmission and
    retransmission Replace the CFN with an absolute, AFN fragment number, with
    a size bigger than the CFN, but need to be defined for different
    technologies o LT: When you send pckts for the 1st transmission and when
    retransmission the AFN is bigger so data is not the same size, how you
    manage the modification in size of the data? o CG: There are different
    approaches, AFN is not defined yet, one possibility is that data does not
    fit all the capacity iin teh tranmission and then is can fit completely the
    packet in the retranmisssion, it is not optimize but it can allow us to
    resend the fragment LT PT: Trouble if we cannot detect then we cannot drop
    the packet LT: Detect can be done using the MIC in the end but do not
    waranty the fragment transmission, so we take the risk to loose the packet
    o CG: first attempt could send les than max so taht the AFN can fit in
    retry, => loss of capacity but I dio not see anither way o AP: I feel that
    AFN > CFN leads to trouble. Need to bo written down o CG: If AFN is
    expected to be as CFN then we cannot said N=A so A not equal to any number,
    for the 1s transmiision we need an extra space, oAP: If we reserve some
    space so A=N and we use A all the time o CG: for the 1st attemp we use a FN
    and not an absolute number o AP: If we have a full window of losses, we
    drop the packet o CG: The probability is low, and we can check with MIC, it
    cannot say which fragment is mising but the error is detected o AP: There
    could be an event that there is a very big lost, so the MIC needs to detec
    thte transmissione rror.  So we need to write down, and see that the
    technology needs to detect and use the MIC o CB: Any MIC has a chance to
    fail. You can also put a received length as an assurance. There are 2
    directions one is more expensive than the other, so both need to be solved
    o CB the size can be in the all ones frame, or in the ack, depending on
    where the cost is o LT: we are fragmenting the uplink not the downlink o
    CB: Optimize for what is really expensive o PT: If the this frame is
    expensive then we can Ack o LT: We need an uplink msg to send a downlink o
    PT: where it is expensive ? Sending ir more expensive than receiving by
    number of bytes, that present iin the ACK, bitmap if self cab give the
    number of bytes o CB: If the ACK bitmap gets too big for the max frag size
    (and ACK is on the expensive direction), maybe use a fountain code and an
    ACK that just indicates the number of fragments missing.  This also removes
    the need for an AFN, as the fountain code would simply continue the CFN
    sequence. o AP: If your CFN is 3 bits the window is 8, even if the SN is
    big you still sending 3 bits in CFN to have enough space for all
    technologies. o PT: We need to study CB input, and also we send 100
    fragments and we lose 10, the FN can express the bytes as the bitmap, if
    loses are less then we indicate the list of the few instead of the bitmap
    than can take a big place o PT: Do we really have this case? o LT/AP: It is
    a possibility to have this, this mode makes sense, when deploying we need
    to consider the number of consecutive fragment lost, to built the packet.
    You use this packet and verify with MIC o AP: This is a good things to
    explore, do we have the 2 modes to solve thes kind of problems? o LT: What
    we have to defin is the format and not the behavior, and when you solve
    this the draft goes faster o AP: agree with Laurent. settle on the format.
    Inclide this behavior makes sense o CG: Other updates made on the draft, o
    PT: We need to discusses more ACK, but sending back the langs , we got them
    all, full bitmap maps once, to get all frames but I need to check the langs
    o AP: bitmap for the windows, to avoid ambiguity o LT: Ambuguity: loosing
    all the packet and receivng an ACK? o PT: That there is not 2 windows when
    it is waiting for an ACK o AP: the proposal the CG gives looks right, but
    not sure if the optimization would work. o LT: AFN is a particular number
    of CFN o PT: The choices will be done by technology. The event of
    retransmission is supposed to be rare. However, more than depending on the
    technology, it seems like it would need to be based on the deployment,
    which is much more complicated o LT: depends also on the application. o CG:
    How each technology will manage the specific issue o AP: Continue further
    on the mailing list. CG: send an email when you can integerate these
    discussion. Diego and JCZ shall review the changes.

*    [7:47] SCHC CoAP (Laurent)                                      [10min]
    o Not covered

*    [7:47] AOB                                                      [ 3min]
    o
    o