Minutes interim-2018-lpwan-05: Wed 17:00

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

Meeting Minutes

   Connection details

*    Date: May 30, 2018
*    Time: 8-9AM DST, 17:00 CEST:
*    Webex Link:

*    Meeting number: 202 477 894
*    Meeting password: QprtWqpe (77789773 from phones)

*    Join from a video conferencing system or application
*    Dial 202477894@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: 202 477 894
*    Global call-in numbers:


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

*    [17:15] SCHC padding - Dominique                                [20min]
*    [17:35] SCHC Tickets and Discussed options - Ana + Laurent      [20min]
*    [17:55] AOB                                                     [ 5min]

Minute takers

*    Ana Minaburo
*    Pascal Thubert
*    Dominique Barthel
*    Carles Gomez
*    Alexander Pelov


*    Ana Minaburo
*    Pascal Thubert
*    Dominique Barthel
*    Laurent Toutain
*    Carles Gomez
*    Juan-Carlos Zuniga
*    Alex Pelov
*    Edgar Ramos
*    Arun Kandasamy
*    Flavien Moullec
*    Diego Dujovne

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
*   Diego Dujovne
*    Pascal Thubert
*    Alex Pelov
*    Laurent Toutain
*    Ana Minaburo
*    Vanessa Valderrama
*    Dominique Barthel
*    Julien Catalano
*    Edgar Ramos
*    Carles Gomez
*    J Sanchez
*    Ramon Sanchez
*    Juan-Carlos Zuniga
*    Felipe Díaz-Sánchez

Action Items
Chairs: find reviewers for drafts


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

*    [17:15] SCHC padding - Dominique                                [20min]
*    [17:35] SCHC Tickets and Discussed options - Ana + Laurent      [20min]
*    [17:55] AOB                                                     [ 5min]


*    [17:05] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts
Alex give the presentation of the meeting
Minutes of the last meeting are approved

Next IETF Meeting request 2h slot
* No more 2.5h slots
* We need to make recharter in this time
* Agree in topics to be discussed
* Only the main points
* List of conflicts, please send a mail before this friday to chairs if you
have a strong feeling * Actions Items:
    * Milestones has been updated
    * We need to find reviewers for the drafts
    * Adoption of the Technology Specific Draft (TSD)
    * Authors of TSD should read the CoAP and the IP/UDP drafts
    * Review need to be done before end of July
Pascal: This could help to better unsderstand what do you need for the TSD
Alex: Contact the technology authors to ask for review.

Ana: ticket 18 has been closed and now it is ticket 27 for the CoAP draft
 Ticket 18 is closed.

*    [17:15] SCHC padding - Dominique                                [20min]
Laurent: Welcome Dominique as author of the draft
Pascal: Chairs  ask Dominique to be author as he has contributed

Dominique: This is an idea reach after a discussion with Laurent
that can make the text and the mechanisms more simple

* current situation: Padding is done at most twice,
* Proposal is to do it at most once before transmission, 7 bits max
* Figure slide 10:
* Byte padding after compression (fill the last byte). If no fragmentation is
needed, then OK. If fragmentation is needed, then the last fragment can be with
added padding * Figure slide 11 showing the packet format, with the padding P1
at the end of the SCHC Packet and P1 and P2 after the last fragment * Only the
last fragment may need additionnal padding. Other fragments don't need added
Padding, because of clever treatment of these cases by the existing draft. * at
reception, since payload is byte aligned, the paddind can be removed, works for
reassembly and decompression * Proposal mechanisms is to pad before
transmission, once after SCHC packet because fragmentation is not needed and
SCHC Packet needs padding or * If you do fragment and get this weird size
fragment, then you pad * The receiver reassembly the fragments of the buffer
and we don't care about the P1 bits, the Decompressor will drop them when
decompressing the packet
 * The problem is that now MIC needs to be computed with the padding in order
 that the MIC check is correct * Notion of byte with a L2 Word to define byte
* There are places that we do define what a "byte" is. So, this notion appears
from time to time. The definition of L2 Word can mean a byte, or a bit, or
something else. * L2 Word may be bit or byte, the SCHC will works good over
both without confussing the description * The MIC will work better (because no
need to add padding) * * SCHC must know the L2 word for each underlying
technology * Dominique: MIC and padding bits should be defined somewhere.
Suggested to be in the technology specific document * Laurent: With CRC, the
position doesn't matter (?) * Laurent: We are transmitting the padding anyways,
so there is no need to specify them explicitly * Dominique: some lines may
prefer a specific value for padding bits * Laurent: better to force them to be
zeros or to be ones * Dominique: question is who decides the values for such
padding bits? * Dominique: what to do for MIC over padding? Should the padding
be covered by the MIC or not? (if yes - simplified treating. if yes - there
must be loopback between decompressor and MIC) * Laurent MIC detects that we
lost a fragment and not an error because L2 CRC is protecting against the error
* Pascal but we need that MIC replace the UDP checksum that will be compressed,
we need a proof that this checks * Laurent: MIC and padding are in the All-1
frag, so they can be generated at the "same time" * Pascal: is there a way to
make the padding self-describe its length? * Alex: like this idea, go with the
simplest possible solution, including tha padding is not difficutl and the
second point is how much time the current implementations need to change this *
Dominique: the edit is already done (branch on Github). See diff at
https://github.com/lp-wan/ip-compression/pull/20/files *Flavien we need bit
stream instead of array: this is not a major change * Dominique (slide 19):
discussion on layering: "kind of" layer violation, but padding bits are not
really processed * Alex: just checking that changes in the document and in
implementations are not majors * Ana: fixed the pull request in the github, so
we can go forward. * Alex: I don't see big issues on the single-padding
proposal, send a mail on the mailing list to announce the changes.

*    [17:35] SCHC Tickets and Discussed options - Ana + Laurent      [20min]
* Alex: no much time... Can you focus no tickets that may require more
discussion? * Ana: 12 open tickets. Most of them will be closed

* Ticket 10: it was possible to have different fragments in different bearers
(?). It is possible with DTAG, but is out of scope for SCHC/UDP/IP. This could
be added in technology specific documents. * Ticket 12: Padding (lots of
discussions) - Dominique presentation. It will be finished to discuss after
mailing list * Ticket 14: Legacy devices - this needs to be studied / defined
in other document (not ot SCHC UDP/IP). Possible item for rechartering * Ticket
20: Definition of 'Byte boundary' and it's representation is to use "Next Byte
Boundary" (instead of Byte Boundary)
   * Laurent: do we use L2 Word instead?
*  * Alex: if it is more clear (L2 word), go ahead. Send an email to the WG
list, and if there are no objections, go ahead. * Ticket 21: It was necessary
to update ticket 15 (the last fragment is 1 bit shorter). * Dominique: are you
sure that's what we've decided? * Ana: yes,.. * Dominique: not sure it's what
he remembers * Dominique: are the bitmaps changing size? * Ana: no, the header
changes size * Can the bitmap be reduced? No? But how does the receiver know
that the C-bit was not there?

* Dominique, Ana and Laurent take this discussion offline.

* Alex: great progress. How many tickets are yet to be closed? Big discussions

* Laurent: sent an email on the Time Scale option on the CoRE WG list

*    [17:55] AOB                                                     [ 5min]