Connection details ------------ * Date: 7-8am US Pacific, 4pm CEST: http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-05-10&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:00]Administrivia [ 2min] o Note-Well, Blue Sheets, Scribes, Agenda Bashing o Approval minutes from last meeting * [7:02] LPWAN Overview (Steve) [ 5min] * [7:07] SCHC IP/UDP Compression (Laurent, Ana, Carles) [40min] * [7:47] SCHC CoAP (Laurent) [10min] * [7:47] AOB [ 3min] Action Items ------------ * Alex: Minute takers ------------- * Ana minaburo * Pascal Thubert * Carsten Bormann * Juan-Carlos Zuniga Attendees --------- * Alex Pelov [x] * Ana minaburo * Arunprabhu Kandasamy * Carles Gomez * Carsten Bormann [x] * Juan-Carlos Zuniga [x] * Laurent Toutain [x] * Pascal Thubert * Samian Kaur [x] * Uday Davuluru Past Attendees (previous meeting, for cc) --------- * 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:00]Administrivia [ 2min] o Note-Well, Blue Sheets, Scribes, Agenda Bashing => Agenda approved o Approval minutes from last meeting => Minutes approved o Alex introdcuces the documents * No changes for agenda * Last minutes are approved * Remmind the charter actions and milestones * Action items from last meeting: Review IP/UDP draft from JC and DD - First Review from JC to Ana, most about confusing terms, - Missed Fragmentation, he has already done SCHC compression part inputs from JCZ is already incorporated version 3 - JCZ will send out New comments for version 3 including the fragmentation part - draft CoAP: CB and MV - not yet done - AP: meeting in person at Prague may be 2hrs - LT: we will need 2hrs if we want to discuss the CoAP part Action Items from last meeting ------------------------------ * [7:02] LPWAN Overview (Steve) [ 5min] o AP: Stephen cannot attend, Alex presenting o Stephen will send revision by Friday, then WG to do review till May 24th, LC ready version by May 30th o Review by working group next week; friday; o Ana: next step to confirm the consensus on the vocabulary; * [7:07] SCHC IP/UDP Compression (Laurent, Ana, Carles) [40min] o Presentor:Ana o changes in schc version3: modifications from JCZ incorporated This modifications seems to bring clearty to the draft o waiting for consensus on end device vs device - Consensus is called it Dev to match acronym o Application sever is now App because there is not necessarily a server, to be confirmed -Consensus is called it App o Added W in NG -> NGW o Comment from JCZ was that the names could be confusion, Function vs. Action. Changing CDF to CDA. o JCZ: I asked people for feedback from external view about readability, thus suggested the changes, in particular for acronyms o JCZ: recommend using the term device, abbrev as Dev. Is that a good idea? o PT: +1; calling for consensus on that o CB: agreement. o AP: agrees with Dev; onem2m calls DA: o PT: Come with proposal and disucss in mailing list o LT: App is fine APP not as ùmuch since people may think it is an acronym as opposed to an Abbreviation; o PT: Agree; App, NGW, Dev. o AP: We need to advance on fragmentation, we have 25mn. o Carles now talks about fragmentation o CG: All changes were added in 03, thanks to everyone for the feedback o CG: for windoow mode, one bit is added (W bit) to avoid ambiguity, as a window flip flop. o Window is complemented to recognize which window is in used o Exmples for the ise of W: The retries will use the same W is used, with the same value o CB: repeating hi o PT do you want no window at all or do you want o CB: Not window at all, the struct of transmission of the single packet is modify, o PT: the window is to avoid ambiguity, the fragment counter is small in size of bits, so there is not enough to number all the fragments, o CB: confusion with the SN o PT: If not trucking this is right but when trucking there is a sequence and we need to avoid ambiguity o CB: It is very expensive to do this o PT: The problem is the number of bits to number, so there is not enough so need a window, nd we need to eliminate the ambiguity o CB: More regular transmission than retransmission, it is more impotant to optimize regular ttransmission than retransmissions o PT: So we need more bits to renumber all this framents o AP: So the MTU is 11 bytes, so we need more than 200 to numebr this fragments o CB: It is not necessary need a window o LT/ Well this is a mechanisms, what the ML think? it is a good solution about the reduction of bits, and it is reliable. What people want to implement and use? o AP: We need to see avout this question, CG find a solution about the previous question about drapping out, so this is solved o CB: RFC 3819, section 8 o CG: Next slides; identify as pending in the lo ast meetings but now is on o CG: Possible solution, with an ambiguity that can arrise, with twoo format for transmission and retransmission Replace the CFN with an absolute, AFN fragment number, with a size bigger than the CFN, but need to be defined for different technologies o LT: When you send pckts for the 1st transmission and when retransmission the AFN is bigger so data is not the same size, how you manage the modification in size of the data? o CG: There are different approaches, AFN is not defined yet, one possibility is that data does not fit all the capacity iin teh tranmission and then is can fit completely the packet in the retranmisssion, it is not optimize but it can allow us to resend the fragment LT PT: Trouble if we cannot detect then we cannot drop the packet LT: Detect can be done using the MIC in the end but do not waranty the fragment transmission, so we take the risk to loose the packet o CG: first attempt could send les than max so taht the AFN can fit in retry, => loss of capacity but I dio not see anither way o AP: I feel that AFN > CFN leads to trouble. Need to bo written down o CG: If AFN is expected to be as CFN then we cannot said N=A so A not equal to any number, for the 1s transmiision we need an extra space, oAP: If we reserve some space so A=N and we use A all the time o CG: for the 1st attemp we use a FN and not an absolute number o AP: If we have a full window of losses, we drop the packet o CG: The probability is low, and we can check with MIC, it cannot say which fragment is mising but the error is detected o AP: There could be an event that there is a very big lost, so the MIC needs to detec thte transmissione rror. So we need to write down, and see that the technology needs to detect and use the MIC o CB: Any MIC has a chance to fail. You can also put a received length as an assurance. There are 2 directions one is more expensive than the other, so both need to be solved o CB the size can be in the all ones frame, or in the ack, depending on where the cost is o LT: we are fragmenting the uplink not the downlink o CB: Optimize for what is really expensive o PT: If the this frame is expensive then we can Ack o LT: We need an uplink msg to send a downlink o PT: where it is expensive ? Sending ir more expensive than receiving by number of bytes, that present iin the ACK, bitmap if self cab give the number of bytes o CB: If the ACK bitmap gets too big for the max frag size (and ACK is on the expensive direction), maybe use a fountain code and an ACK that just indicates the number of fragments missing. This also removes the need for an AFN, as the fountain code would simply continue the CFN sequence. o AP: If your CFN is 3 bits the window is 8, even if the SN is big you still sending 3 bits in CFN to have enough space for all technologies. o PT: We need to study CB input, and also we send 100 fragments and we lose 10, the FN can express the bytes as the bitmap, if loses are less then we indicate the list of the few instead of the bitmap than can take a big place o PT: Do we really have this case? o LT/AP: It is a possibility to have this, this mode makes sense, when deploying we need to consider the number of consecutive fragment lost, to built the packet. You use this packet and verify with MIC o AP: This is a good things to explore, do we have the 2 modes to solve thes kind of problems? o LT: What we have to defin is the format and not the behavior, and when you solve this the draft goes faster o AP: agree with Laurent. settle on the format. Inclide this behavior makes sense o CG: Other updates made on the draft, o PT: We need to discusses more ACK, but sending back the langs , we got them all, full bitmap maps once, to get all frames but I need to check the langs o AP: bitmap for the windows, to avoid ambiguity o LT: Ambuguity: loosing all the packet and receivng an ACK? o PT: That there is not 2 windows when it is waiting for an ACK o AP: the proposal the CG gives looks right, but not sure if the optimization would work. o LT: AFN is a particular number of CFN o PT: The choices will be done by technology. The event of retransmission is supposed to be rare. However, more than depending on the technology, it seems like it would need to be based on the deployment, which is much more complicated o LT: depends also on the application. o CG: How each technology will manage the specific issue o AP: Continue further on the mailing list. CG: send an email when you can integerate these discussion. Diego and JCZ shall review the changes. * [7:47] SCHC CoAP (Laurent) [10min] o Not covered * [7:47] AOB [ 3min] o o