Minutes interim-2018-lpwan-02: Tue 17:00
minutes-interim-2018-lpwan-02-201801301700-02
The information below is for an old version of the document.
| Meeting Minutes | IPv6 over Low Power Wide-Area Networks (lpwan) WG Snapshot | |
|---|---|---|
| Date and time | 2018-01-30 16:00 | |
| Title | Minutes interim-2018-lpwan-02: Tue 17:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-01-30 |
minutes-interim-2018-lpwan-02-201801301700-02
Connection details ------------------ * Date: January 30, 2018 * Time: 8-9AM DST, 17:00 CEST: https://www.worldtimebuddy.com/?qm=1&lid=2988507,1816670,5391959,5128581&h=2988507&date=2018-01-16&sln=17-18 * Webex Link: https://cisco.webex.com/ciscosales/j.php?MTID=mdde5e47d87e5077bd7f70da47a7ffae7 * Meeting number: 204 648 433 * Meeting password: 62YbPWpj (62927975 from phones) * Join from a video conferencing system or application * Dial 204648433@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: 204 648 433 * * Global call-in numbers: * https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=410481357&tollFree=1 Agenda ------ * [17:05] Administrivia [10min] o Note-Well, Scribes, Agenda Bashing o Status of drafts * [17:15] SCHC WGLC [30min] * [17:45] CoAP SCHC [15min] * [17:55] AOB [ 5min] Minute takers ------------- * Dominique Barthel Attendees --------- * 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 from last time ---------------------------- * Juan Carlos Review Minutes ------- Agenda ------ * [17:05] Administrivia [10min] o Note-Well, Scribes, Agenda Bashing Since last meeting : two more reviews received (Dominique, Edgar), expecting one by Juan Carlos tonight o Status of drafts * [17:08] SCHC WGLC [30min] Ana: gives the ball to Carles Carles: processing the last round of reviews. No slide at this time could use this time to discuss the most prominent/general/technical comments (as opposed to editorial). or complete presentation left over from last interim? Alex: pick the main ones (among the non-editorial). Ana: opened some tickets. Automatic notification mails not working. 11 open tickets right now. #6: fully-used All-0 or All-1 window. Laurent: when full window cannot be sent. In ACK-on-error, device knows this limitation, so knows when to ACK or not. Ana: propose to use this for ACK-always. No objection #2: default value for Hop limit? no default. Because we assume the LPWAN has no loop, Hop limit is of no use. In a topology with risk of loop, field should be sent (potentially on fewer bits). #8: possible to have different Rule IDs with same DTAG? DTAG is for fragmentation. Laurent: Rule ID defines processing, DTAG defines packet that is being fragmented. Dominique: If Rule ID describes fragments vs. ACKs, then you can litterally have different Rule IDs with the same DTAG. Was that the question? #9: Laurent: protocol is flexible enough to support reordering between RGW and NGW. Dominique was to check the situation with LoRaWAN. Edgar: comment that re-ordering should not happen between RGW and NGW is not needed. Works anyway. JCZ: most of my comments on clarification of the architecture definition. Suggest keeping the text assuming a star topology, just to avoid opening a can of worms. Ana: packet duplpication as already discussed when reviewing the state machine. The state machine drops duplicate packets. Edgar: this was the fragmetnation state machines. How about compression state machines? Edgar: commetn was mainly about possiblity that tje decomporessor would receive twice the same packet, amybe even once fragmented adn once not fargmented. Laurent: not our problem. Compressor will still work Edgar: looking at making this future proof if we go beyond star topology. Laurent: forwarding capability works. But we don't want routing protocol, etc. Laurent: we can start with this, and if we see a need/problem we'll write another document. Carles: re-ordering prblem in ACL-always, last windows compreises several fragmetns, 6,5, 4, 7. If 7 arrives frist at receiver, does the mechanism still work ? In ACK-always, bleive yes, albeit less eficiently. Laurent: the last window now behaves the same in ACK-always and ACK-on-error. <<< sorry I was interrupted, missed a minute or so of the meeting. Please help filling in the blank >>>> Pascal: thought we hasd a corner case in the last window. Are you sure it works? JCZ: referring to the reason why we put the MIC? Pascal: no, MIC is much older. Discussion at the last interim. Don't remember. Edgar: Laurent: "out of sequence" instead of "re-ordering". Carles: "assume that out of sequence will not happen". Pascal: even if rare, if it happens, we accept it. Did not do my review with this assumptation. If we say re-ordering is possible, need to redo the review with this assumption in mind. Edgar: Laurent: could we keep a "no re-ordering assumed"in the SCHC document, and in the technology dcument "after frther examination, a reordering of so much is acceptable". #11 padding in ACK? Laurent Edgar: comment about the whole padding thing. NB-IOT does not need byte alignement of the payload. There is padding a Layer 2 anyway. Does padding need to be here, or should be left to the technology dcument? JCZ: agree to remove it from the general SCHC document, and leave it to the technology documents. Ana: several months ago, decided that padding was best put at the end. Edgar: padding here is to achieve byte alignement. Also filling a transport block. leave the latter to the L2. The former may not be needed on some technologies. Carles: the SCHC doc could mention the two options (padding between header and payload or at the end). Leave to the tech document to select. Edgar: rather have only one specified, and activate it or not. Otherwise interop will be hard, especially multi-RAT networks. Laurent: in LoRa, we (Acklio?) use the FPort byte to carry the Rule ID, in one full byte. Some form of padding! Laurent: Ana: suggests to have a DEFAULT specification in the SCHC document, and leave it to the technology document to specify differently if it wants! #10 interleaving possible between fragmented and non-fragmented packets? yes. Rewriting of text? JCZ: interleaving of different fragmented packets? Laurent: yes, they have different DTAGs. Edgar: will see devices multi-RAT. Also, on NB-IoT, several bearers of different characteristics. Fragmentation might be needed on one bearer and not on another one. Are the instances of compressor/decompressor one per radio access or one per bearer? Carles: for compression, rules could be the same even cross different radios. Fragmentation need to be specific. JCZ: Laurent: the current description only aapplies to a single bearer. Edgar: you mean one entity per Laurent: current description is for a single radio. could extend model e.g. with different rules for different bearers. Pascal: this goes beyond to initial goal. Edgar: would avoid this spec to be limiting us in the fture. Pascal: can be made to work with a set of rule per bearer. Edgar: LTE-M is a bit more dynamic, switching from one bearer to another. Fear that this approach might be a limitation. Maybe as JCZ says, compressed could be same, fragmentation changed when changing bearer. Pascal: same with LoRaWAN. Cannot switch SF in the middle of a fragmented packed. Esgar: similar, even worse with LTE-M. Pascal: changing MTU, IP above it should know. Edgar: maybe you're right, hae to have a maximum MTU. Pascal: based on this discussion, start closing some ticket. Ana: will open a new set with Edgard's and Dominique's comments. Pascal: Edgar, keep us updated on NB-IoT's constraints and characteristics. [18:03] meeting conludes * [17:xx] CoAP SCHC [15min] * [17:55] AOB [ 5min]