Connection details ------------------ * Date: January 16, 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/cisco/j.php?MTID=m016ded95875427897fd1089cb921b30bbPWpj * 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 ------------- * Ana Minaburo * Pascal Thubert * Dominique Barthel * Diego Dujovne Attendees --------- * Pascal Thubert * Alex Pelov * Laurent Toutain * Ana Minaburo * Diego Dujovne * Dominique Barthel * Julien Catalano * Edgar Ramos * Carles Gomez * Ivaylo Petrov * Juan-Carlos Zuniga * Felipe Díaz-Sánchez * Vincent Audebert 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 Action Items from last time ---------------------------- * Update SCHC draft * Review from Dominique Barthel, Edgar Ramos, and Juan-Carlos Zuniga for January 23 Minutes ------- * [17:05] Administrivia [10min] o Note-Well, Scribes, Agenda Bashing * Alex presents the usual introduction * items to be added to the agenda? None. Agenda approved. * comments on the minutes of last meeting? None heard. Minutes are approved. * last meeting actions items: MIC discussion and SCHC WGLC. Both took place and will be discussed today. o Status of drafts * [17:15] SCHC WGLC [30min] Edgar, JC and Dominique will provide reviews in the next couple of days. By end of week probably, early next week at the latest. Pascal: the call will continue until the 23rd. We have February to solve the issues. Ana: thanks all the reviewers. Discuss today the items coming from reviews received in the mailing list. Review from Steven: - zip bomb: does not seem to be possible. We know what we are doing. Agree to put the suggested comment into the document. LT: a risk of staturating the link with variable length fields - suggested DNS look-up so that device send name instead of address. Ana: out of scope of this document, does the group agree? Pascal: Edgar: IP is stable even when movement, may be in roaming Pascal: if IP address of application server is changed, we need to download new rules in the device. Need to think about it. Laurent: this doc is about compression. Comparing bits. Not the way the context is installed. Pascal: should be in a new document. Add a sentence that say that the rule may be changed but it will be specified in another document Review from Pascal: - simplify abstract: will do - default Rule ID size? size depends on the technology. Pascal: say at the begining that other documents will specify more specific behaviors. Pascal and Dominique: is Rule ID constrained by byte boundaries in any way? See Figure 16. Clearly state if it is or it isn't, early in the document. Edgar: depends on whether fragmentation is mandatory in all implementations. Carles: Figure 16 and 17 are example. Pascal: Figure 10. JCZ: clarify that Rule ID size is not constrained by alignment. Pascal: technology document will describe if Rule ID is constrained by alignment for a particular technology. Generic SCHC does not place such a constraint. - fragmentation and compression are described together in the architecture. Suggestion to have them decoupled. Fragmentation may be done at application server, etc. Pascal: Laurent: separate compression for CoAP and for UDP/IPv6. Can be bunched together later. Recommend to keep fragmentation and compression together. Edgar: Some technologies has multiple reception points, which means that the reconstruction of the packet (if fragmented) has to be done in a point after the combining of packets is done. This restricts the places where the fragmentation is placed. In practice, this might be very close or just same place where the decompresion happens. Ana: we can have a SCHC function in various places of the architecture. Each instance can do either one or both of fragmentation and compression. Alex: add a sentence in the doc? Pascal: curious that the doc need a lot of changing if SCHC is divided in compression and fragmentation Ana: It is in the document, but for now you always have SCHC and fragmentation together in the same place. Maybe in the future we can have them split into multiple places. Edgar: on first reading, had difficulty understanding the flow. What is supposed to happen, in what order? the doc goes back and forth between compression and fragmentation. Edgar: especially the compression section seems less clear on the flow, the mechanism. The connection between the two (frag and compr) is not clearly described either. Pascal: inherited from the 6LoWPAN mindset Ana shows a diagram with compressed packet followed by the fragmentation. Dominique: we need to come up with a name for the "SCHC packet". The text currently uses various circonlocutions for it. - Pascal: some sentences could be written in clearer English. Beleives that the intended meaning is what we want, but the way it is expressed might be misleading. Ana: The window does not have to be full, Pascal: in section 5.5: In the introduction "The FCN will be assigned sequentially in a decreasing order starting from 2^N-2". Ana: remnant from old text. Will be corrected. Pascal: challenges that Ack-on-error works if first FCN is not necessarily 2^N-2 Laurent: 2^N-2 is not mandatory. Can work without. Gives more freedom. Benefit is ??? Pascal: creating new problem for Ack-on-error. Laurent: we recommend to use the whole window (i.e. FCN starting at 2^N-2) but we don't want to mandate it. Pascal: then write what is the price/risk if you don't. Carles: agree that for Ack-always, 2ˆN-2 is not mandatory. Alex: write recommendation. - non-reordering: Laurent states that the protocol can now deal with re-ordering. We originally had this statement about LPWAN networks not re-ordering packets but we can remove it. Carles: Also in no ack mode. Laurent: even if a few fragments arrive out of order, no problem. Pascal: Keep the text as it is. The current text is consistent. Reordering may create many weird cases. Don't try to be better than you need because there is an associated cost. We don't support out of order fragments. Dominique: Out of-order can happen between multiple gateways and the NS. The point is valid to know if current SCHC works in presence of re-ordering or not. We can limit reordering to a limited time. Pascal: connection times between gateways and NS are nothing. Dominique: some early gateways use 3G for backhaul. Can have up to one second of delay. So out-of-ordering could take place between a 3G gateway and a wired gateway. Julien: The LoRaWAN system is made to keep the frame order. The NS will put frames in order before delivering to the upper layer. Dominique: pretty sure I saw out of order packets in a LoRaWAN system but, thinking about it, it might have been on the wireless logger interface, maybe not on the data interface. Dominique: will check anyway with Orange experts whether OoO can happen on the data interface. Edgar: Got a bit confused from the previous discussion since assumed that LORA has the combining of the packet in the network gateway that connects multiple base stations, and according to the SCHC architecture drawing the SCHC functions are located after the network gateway, not between the network gateway and the base stations. Just wondering if then this wasn't intended like that. [18:00] meeting ends * [17:45] CoAP SCHC [15min] not addressed for lack of time * [17:55] AOB [ 5min] not addressed for lack of time