Connection details ------------------ * Date: December 19th 2017 * Time: 8-9AM DST, 17:00 CEST: https://www.worldtimebuddy.com/?qm=1&lid=2988507,1816670,5391959,5128581&h=2988507&date=2017-12-05&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 [05min] o Note-Well, Scribes, Agenda Bashing o Status of drafts (WGLC / forthcoming WGLC) * [17:10] SCHC MIC selection [25min] * [17:35] SCHC update and Discussion: WGLC ready or not ready [20min] * [18:00] AOB [05min] Minute takers ------------- * Ana Minaburo * Pascal Thubert * Dominique Barthel Attendees --------- * Pascal Thubert * Alex Pelov * Laurent Toutain * Ana Minaburo * Felipe Díaz-Sánchez * Dominique Barthel * Juan-Carlos Zuniga * Julien Catalano Past Attendees --------- * Alex Pelov * 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 Minutes ------- [17:05] Administrivia [05min] o Note-Well, Scribes, Agenda Bashing * Pascal: IETF meeting, taking minutes. o Status of drafts (WGLC / forthcoming WGLC) * Pascal: two presentation to finish the work on SCHC * Last call was deferred waiting for the MIC resolution [17:10] SCHC MIC selection [25min] * Laurent: I made some simulation on CRC to detect fragment loses during the transmission. * Detect error and eliminate UDP checksum to have a good compression * Use 16 CRC but is not efficient or CRC32 that takes more place that may take 2 bytes as UDP checksum * describes simulation setting: random data (uniform), exhaustive list of possible fragment losses. * computes CRC with fragment loss, if identical to CRC without fragment loss then it's a mis-detection problem. * Juan Carlos: do you cnisider burst errors? You mentionned tat you tested combinatio , which? * Laurent: I tests all the losses without any distribution, all the combinations not related to a pattern *Dominique: the error model is that a fragment is present on the receive side or not ? Laurent: yes. * Laurent: could argue that successive fragments are more likely to be lost together than remote fragments. * Laurent: I did not study lost packets only error in all the received packets * Laurent: I only take 16 fragment as a max number, I don't think we will use larger FCN number * describes simulation results. With CRC16 and 20 fragments, about 15 mis-detection cases across the 2ˆ20 possible cases. * Dominique: 5 missing fragments is likely so the chances of getting a false positive (good CRC for a wrong packet) exist in practice * trying out different CRCs. Similar strength. Tried MD5 hash as well, used first 2 bytes as MIC. Works equally well. * with CRC32, no mis-detection. Nor with 3 (or 4?) bytes of MD5. * more work needed on this. * conclusion: CRC16 not good when more than 8 frags. CRC32 is perfect, but needs 2 more bytes, so could send length instead and keep CRC16. * proposed options: include length and do not compress UDP checksu; mandate CRC32c; mandate CRC that fits the number of fragments; use CRC16 and live with mis-detections. Anyway, this would be a recommendation, that can be overridden by the SCHC-over-foo document. * JCZ: A good conclusion is using CRC16 to protect less than 8 number of fragments * JCZ: But if we need a one single method to support for the general solution can be CRC16 * Pascal: It is also good to define the correct CRC in the foo documents. * Pascal : fragmentation is very specific to the technology, more than * Pascal: use SHOULDs, let SCHCover-foo override this. * JCZ: we want a baseline behavior in this doc. The MUSTs must be in the SCHC-over-foo doc. * Pascal: this doc should say "at least as good as CRC16" because of UDP. * Pascal: CRC32c seems beyond the need. Do we stick with CRC16 or add the Length field? * Laurent: if we transmit a number of fragments, cannot change size of fragments during transmission. * Pascal: thought we had made a decision not to change the fragment size during transmission of packet. * Pascal: think we said we would use MIC instead of length for that very reason: change the fragment size on the fly. * JCZ: * Pascal: number of fragments and CRC. * Laurent: CRC24 could be good. Not trie, but tried 3 bytes of MD5. * Laurent: could take the risk of CRC16. * Laurent: in the proposed solution, we dont use the fact that fragment are lost, not bits. With good code theory, we could do better with 4 bytes, or same on 3 bytes only. [17:35] SCHC update and Discussion: WGLC ready or not ready [20min] * Ana: -v8 issued. Some inputs by Carsten today. * added intro to fragmentation, added fragmentation terminology in the terminology section. * asks the audience opinion about swapping the two sections 5.2 and 5.3 * Pascal: usually frame formats before behavior. * Ana: regarding Abort frames. Distinct Abort frames for sender and receiver. Both ends should abort in either case. Do we want to ACK aborts or not? * Laurent: forgot what was decided in Singapore (if anything), but today think we should not ack an abort. * Laurent: and now, we also have a timer. * Ana: make decision now that Abort is not acked. Because we have timers everywhere. * Ana: * Laurent: will complete study on CRC by end of week. * Pascal: will launch WGLC end of week. For how long? Can reviewers read by Jan 16th? * Pascal: will launch WGLC ending on Jan 16th. [18:00] AOB [ 0min]