Minutes interim-2020-lpwan-08: Tue 16:00
minutes-interim-2020-lpwan-08-202005191600-00
| Meeting Minutes | IPv6 over Low Power Wide-Area Networks (lpwan) WG | |
|---|---|---|
| Title | Minutes interim-2020-lpwan-08: Tue 16:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2020-05-19 |
minutes-interim-2020-lpwan-08-202005191600-00
Connection details
------------------
• Date: 7-8am US Pacific DST, 4pm CEST:
https://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2020-05-19&sln=14-15
JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m45866408ff12537a6fbaefaa37cf97a0
Meeting number (access code): 619 208 505
Meeting password: tG99jRSJgJ9
JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)
Tap here to call (mobile phones only, hosts not supported):
tel:%2B1-650-479-3208,,*01*619208505%23%23*01*
JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:619208505@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.
Join using Microsoft Lync or Microsoft Skype for Business
Dial sip:619208505.ietf@lync.webex.com
Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX000029055
Participants:
* Watson Ladd, Cloudflare
* Laurent Toutain, IMT Atlantique
* Ana Minaburo, ACKLIO
* A Paventhan, ERNET India
* Pascal Thubert
* Laurent Toutain
* Alexander Pelov
* Dominique Barthel
* Juan Carlos Zuniga, Sigfox
* Ivaylo Petrov
* Olivier Gimenez
* Eric Vyncke, Cisco
* Diego Dujovne, UDP
* Vincent Audebert
Previous for cc
------------------
- Dominique Barthel
- Arunprabhu Kandasamy
- Ricardo Andreasen
- Diego Dujovne
- Olivier Gimenez
- Carles Gomez
- Juan Carlos Zuniga
- Ivaylo Petrov
- Julien Catalano
- Vincent Audebert
- Ana MInaburo
- Laurent Toutain
- Alexander Pelov
- Sergio Aguilar
Agenda
------
[16:05] Administrivia [ 5min]
o Note-Well, Scribes, Agenda Bashing
o WG Status
[16:10] SCHC-over-LoRaWAN Update [30min]
[16:40] SCHC-over-Sigfox Update [10min]
[16:50] AOB [ QS ]
Minutes
------
[16:05] Administrivia [ 5min]
o Note-Well, Scribes, Agenda Bashing
o WG Status
* Alexander presents the introduction, IPR BCP etc...
* Meeting is not recorded, presence is recorded
* 2 agenda items; no change proposed
* minutes of last meeting are approved.
* Ana reports she's working on Security Section for coap draft, to be
published then. * WG adoption for the OAM draft? Authors would like to
switch to XML v3 and SVG drawings. * let's decide to drop SVG drawings,
convert the current text to xml v3 and then edit xml as source code.
And use XML tables. * will be asked to report at next meeting.
[16:19] SCHC-over-LoRaWAN Update [30min]
* Olivier reports on version -08
* WGLC ended May 8th
* Olivier browses through the comments
* Terminology IETF vs. LoRaWAN
Eric: Let's use IETF terminology and let's make sure the mapping is present
in all WG documents. Let's be consistent with the terminology in all drafts
from this WG. Pascal: Most reviews are going to be from this WG, so it
makes sense to use IETF terminology. JCZ: There are some updates on the SF
terminology that might need to be done if the table with the mapping is
included in some draft. Pascal: object to the use of the term "session" for
the fragments of a same datagram Laurent: Don't talk about implicit DTags
as it might be confusing - just talk about RuleIDs. Olivier explains why
retransmission timer are not used JCZ: I agree. The same issue applies to
Sigfox. Laurent: in uplink for example, sending... what is the case? JCZ:
It is application dependent as you don't know how it will behave as it
depends on the device and the usecase. You can not have a precise timer.
Pascal: So you are arguing that the timer should be big Dominique: could
you still have a Retransmission Timer to rell that it is time to try to
resend, and lower layer will send whenever available? Olivier: If you can
not send it right away, what do you do? You drop it or you queue it.
Pascal: You have different strategies, but people that create the devices
should make sure there are not more applications than could be supported.
Laurent: You don't want to do an ack-request? Olivier: For uplink you could
have retransmission timer. Olivier describing Class A ACK-Always downlink
problem with the timer. If ACK no received at core, can Laurent: You are
aiming at supporting classes A, B and C, right? Olivier: We are aiming in
something simple. Most people are using class A anyway Laurent: Maybe don't
exclude the retramission timer from the draft, but recommend against its
usage for class A devices. Pascal: ... Olivier: You are not getting stuck,
because you have the inactivity timer. Dominique: It seems that you cancel
everything when you lose one fragment?? Laurent: You don't want to fix
value for the retransmission timer - it will be based on application and
radio conditions. Can we put that it will be specified by implementers.
JCZ: It is application dependent. Alex: In some cases you would be able to
know how much traffic the device generates on average. In other you don't
know. Can we have an estimate done on the GW. Laurent: Both ends need to
agree on the value. Olivier: I don't think they need to have the same value
- for uplink the GW does not need to have specific retransmission timer.
Olivier: For uplink - set by the application. For downlink Pascal:
Generally you generate the message, but you add a timebomb or something or
you let the lower layer Laurent: Retransmission timer is the time during
which we cannot send retransmission. We can send ACK REQ after this period.
In a fluid network it will be just after the expiration. In a slotted
network it is the next transmission opportuninity. Olivier - do we need to
be explicit about All-1 Pascal: yes, please be explicit.
[16:40] SCHC-over-Sigfox Update [10min]
JCZ presenting the changes for 02
JCZ: Similar issues like the LoRaWAN draft regarding retransmission timers
and DL Class-A restrictions. JCZ: All-1 using Seq # from Sigfox. Laurent:
You do not interleave non-SCHC traffic, right? JCZ: I guess what you are
asking is if the sequence counter is generic for all applications sending
data and not necessarily SCHC specific? Dominique: Yes, it seems that you
are re-using the counter, but if you don't know if there could have been
other traffic, you can now that you did not lose anything, but if you lost
something, you can not know if it was SCHC-related or not. JCZ: We will
look into that and will provide details.
[16:50] AOB [ QS ]