Minutes interim-2017-lpwan-01: Wed 16:00
minutes-interim-2017-lpwan-01-201704261600-02
| Meeting Minutes | IPv6 over Low Power Wide-Area Networks (lpwan) WG | |
|---|---|---|
| Date and time | 2017-04-26 14:00 | |
| Title | Minutes interim-2017-lpwan-01: Wed 16:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2017-04-26 |
minutes-interim-2017-lpwan-01-201704261600-02
Connection details ------------------ • Date: 7-8am US Pacific, 4pm CEST: http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-04-26&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:05]Administrivia [ 2min] o Note-Well, Blue Sheets, Scribes, Agenda Bashing o Milestones • [7:07] Status of drafts (chairs) [ 5min] o Close to WGLC? • [7:12] LPWAN Overview (Steve) [10min] • [7:22] SCHC IP/UDP Compression (Laurent, Ana) [15min] • [7:37] SCHC Fragmentation (Carles) [15min] • [7:52] SCHC CoAP (Laurent) [ 5min] • [7:57] AOB [ 3min] Action Items ------------ • JCZ, DD: Review IP/UDP drafts • CB, MV: Review CoAP draft • Ana: Post to the mailing list with the terms that we want confirmed Minute takers ------------- • Arunprabhu Kandasamy • Diego Dujovne • Pascal Thubert Attendees --------- • 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:05] Administrivia [ 2min] o Note-Well, Blue Sheets, Scribes, Agenda Bashing * o Milestones * • [7:07] Status of drafts (chairs) [ 5min] o Close to WGLC? AP: Discuss the current drafts. PT: Changed the SCHC to 20mins for Carles to have enough time to explain AP: Two chartered items. AP: Next Deadline :LPWAN specification to IESG PT: Last call for LPWAN overview? we are late. Keep the structure as it is now. PT: IETF 98 Action items overview. Announce discussion of SCHC IP/UDP/CoAP structure. Follow-up to PT: Identified reviewers for CoAP draft? JCZ: agreed to review IP UDP SCHC draft. PT: J-C Zuniga and Diego Dujovne are assigned the in-depth review for the lpwan group PT: WiSUN contribution follow up Confirming IETF 98 assignment for SCHC CoAP draft in-depth review: Carsten Bormann, Michel Veillette PT: To Paul Duffy: we have always considered WI-SUN, Bob has not yet delivered. PT: Paul volunteering for the contribution from WiSUN PT: publish anyway documents , from Paul Duffy. Ana: discussion on the architecture - do we need to have one? Do we agree on the terminology? SF: WiSUN slide: no references on the Slide PD: Can't reference the spec, due to confidentiality. Can't allow direct access to technical specification. PT: Sigfox progressing with ETSI SF: contact offline with PD for references? https://tools.ietf.org/html/draft-ietf-lpwan-overview-01#section-2.4 SF: chairs to ask the working group for the draft's status • [7:12] LPWAN Overview (Stephen) [<<10min] o [Stephen]: * Issues to chat about: - Wi-SUN references? If none, then what? options: 1) ok as-is without refs 2) remove section 2.4 3) something else Other issues can be taken to list before WGLC and/or while editing -02 (next week) Editor will propose change or PR to list for stuff like that • [7:22] SCHC IP/UDP Compression (Laurent, Ana) [15min] AP: Terminology needs to be cleared out. Ana: wants to know if everybody agrees with the naming terminologies with the schc. PT: List the terms which are casting stone. Which are relevant on the mail. LT: on the SCHC draft there is an architecture description graph PT: Ana will take 4 or 5 more important items to give the possible terms, Put the terminologies on the mailing list. Ana: Third version of the draft. Input from the list -> changes made for SCHC compression. Do you agree to put a direction of the compression on UDP/IP compression? Bidirectional? At least for all the fields of the header,(at least hop-limit) could change from uplink to downlink How could this affect the compression? PT: It makes sense to put this rule to SCHC, so all the rules are described in one document JC: Directional? Could also apply it to be ?? (bidirectional?) Ana: IP/UDP Bidirectional, explicitly bidirectional or nothing, and assume that it will be bidirectional. CoAP says it will be (bi?)directional PT: having IP draft with directionality would be a good thing. JC: Is it more generic? looks alie a good idea isf there is no cost. Do we lose anything by doing this? Ana: Any quesstion for the position: List of values to use, like IP address, which we can use for each device. It is added to the UDP/IP draft as directional Ana: introduced for Coap to compress the URI; direction and postion would be important? LT: Position will be 1 on all fields on UDP/IP PT: if we have Routing headaer; position for extension header default to 1? LT: We don't look at extension in the draft. PT: A second release can add this option on the header. We already have the method. Ana: using LSB, Optimizations for the compression? LT: less useful for IP/UDP; coap it is useful. PT: Do you think we are reaching a stable state on this document? LT: yes, personally. PT: Two official reviewers, when to trigger them? LT: it is almost ready. PT: Publish and launch last call LT: it is on the github, can issue 03 on request. Wait the fragmentation part to trigger the reviewers ho • [7:37] SCHC Fragmentation (Carles) [20min] CG: date has been based on the meetings and feedback from the mailing list. CG: first update: new section on reliability option on fragment delivery. CG: comments on posible use of NACK. bitmap provide information about lost fragment CG: New terms used on github replacing the old names. CG: No ACK not tied to Packet/window mode. CG: one issue: if ACK is lost then sender assumes is successful. CG: WM/ ACk on error, no use case identified ? PT: design index for each packets in window. more bits means larger the window; draft doesn't say how many bits, up to the decision of the implementor. CG: Whether will be possible to interleave fragments with different IPv6 packets? D-Tag will be used to distinguish these packets CG: will it be possible to allow frag/ no frag ipv6 datagrams. ? answer is YES! Rule ID for datagrams of each IPv6 packet are different LT: Likes the decision to add DTag field. Include D-Tag field in the ack to distinguish the fragment what happens when last fragment is lost? CG:The receiver does not receive the last fragment the ACK is not trigger, so CG:Timer will be used to send the Ack on Error Ana: Timer will be used at the same time when there is no error? CG: another timer for ACK always option. CG: Ack always: start timer upon sending last fragments, and timer expiration when no ACK. LT: 2 cases are almost same behavior. agree with the current proposal. PT: Timer value is dependent on the direction(sender as device/network) and technology. CG: to be defined in the technology specific profiles? CG: proper name of the timer in each case to be added CG: Packet mode problem: Ambiguity on the receiver side when retransmission of the fragments The idea is to renumber the fragments in the retransmission CB: What case are we optimizing 90% or 10% loss?; be less optimal, looks good for one round of retransmission. PT: need a format for the tries and retries. LT: what happen when you retries the retries PT: the problem will be when crossing the renumbering fragments between the énd and the next retries CB: timer controlled transmission introduces ambiguity. PT: echoes Carsten CB: what range of asymmetry do we address here? 1-20, 1-80? sending the bitmap on the ack is too expensive CB: Sender has to compute something like FEC PT: Can take the discussion further in the mailing list. Asymmetric is more about the number of packets, and not the number of bits Prove that we can live with the renumbering? if not introduce the asymmetric level PT: don't think bit map would be too expensive. JCZ: cost may be different depending upon the direction. PT: address the problem of sending less bits than the bit map CG: pending items ; main questions are solved or some proposal available. PT: prepare the document for publication, needs to start the review process. • [7:52] SCHC CoAP (Laurent) [ 5min] LT: Nothing for CoaP; can be asked in the mailing list. see if we can apply compression schemes for CoMI, Lightweight M2M. AP: working on CoMI. still last minute modification. to be resolved next week and can provide update in the next interim. • [7:57] AOB [ 3min]