Subject: [lp-wan] Meeting Minutes, LPWAN Interim Wednesday May-10-2017

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 May 2017 15:21:53 +0000

Dear all

The minutes and proceedings are uploaded on the IETF site, https://datatracker.ietf.org/meeting/interim-2017-lpwan-02/session/lpwan  

As they stand at this time, they are as below. Please let us  know if we need to change anything:

Connection details
------------
*    Date: 7-8am US Pacific, 4pm CEST: http
://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&dat
e=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 
*    Juan-Carlos Zuniga
*    Laurent Toutain 
*    Pascal Thubert
*    Samian Kaur 
*    Uday Davuluru

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