Connection details ------------------ * Date: September 19th 2018 * Time: 8-9AM DST, 17:00 CEST: https://www.worldtimebuddy.com/?qm=1&lid=2988507,1816670,5391959,5128581&h=2988507&date=2018-09-19&sln=17-18 * Webex Link: https://cisco.webex.com/ciscosales/j.php?MTID=m7933acfc5befd0ac211e03ee678e5a1d * Meeting number: 203 710 782 * Meeting password: JM3Y2Kqf * To join by phone or other means, please go to the Webex Link for details. Agenda ------ * [17:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts * [17:10] SCHC Updates since last Interim - Dominique [15min] * [17:25] Open window Full proposal - Laurent [15min] * [17:40] Open discussion on Fragmentation [15min] * [18:00] AOB [ 0min] Minute takers ------------- * Ana Minaburo * Pascal Thubert * Dominique Barthel Orange * Carles Gomez * Alexander Pelov Attendees --------- * Ana Minaburo * Laurent Toutain * Pascal Thubert * Alexander Pelov * Carles Gomez * Dominique Barthel * Vincent Audebert * Juan Carlos Zuniga * Edgard Ramos * Julien Catalano * Sivasothy Shanmugalingam * Flavien Moullec * Ivaylo Petrov Past Attendees --------- Action Items from last time ---------------------------- * Chairs: find reviewers for drafts Minutes ------ * [17:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts Pascal: Gives Note Well, if you know an IPR or something more to discuss today, present is taken Pascal: Early Bird is was very early, last week, there is a middle price. Register if you want to come Pascal: Next friday is the cut-off for the request of WG meetings Pascal: Priorities, are you agree? if you need a change please tell Pascal as soon as possible (e.g. people who might want to attend also IEEE meeting might be interested in having lpwan late in the IETF week) * [17:10] SCHC Updates since last Interim - Dominique [15min] DB: The changes are in the github, if you want to see what I've done, please read the changes, if you have some comments please send DB a mail DB: Section 4 redundancy has been removed, and put it in 8.2. The W window field now is M bits wide in anticipation for new Ack-on-Error mode, lets see the next presentation to decide if we keep this part DB: In No-ACK used a little bit different things so there is toolbox with the options and the description is given in each mode. The text for sender and receiver needs a littlemodifications to clarify the behavior of each one. DB: Now is missing the Abort part, the version-16 does not have abort neither so we need to introduce when to use the sender abort and receiver abort. Pascal: we need to agree about the Abort behavior DB: in the ML? [see discussion at the end of this timeslot] DB: Question Receiver Abort is not strictily an Abort DB: Discussion on ML to make MIC optional, seemed to reach agreement. Do we need a ticket on this if only to document the decision, since this is a sensitive issue? PT: yes please send this discussion to the ticket trac DB: Optional MIC needs a decision (and a ticket). will see to register to the ticket tracker and create the ticket. PT: Idealy you need to cover the samething that the checksum covers, in order to eliminate the checksum. The MIC is computed after compression so it covers the compression and detects error. LT: So the MIC is not optional PT: Yes, it is; but the discussion is more difficult than only the covering If SCHC does not compress the checksum the MIC could be optional, but if SCHC compressed it then we need the MIC DB: ACK-Always text will be updated next now that we are warmed up on No-ACK. Tt is a little bit more complicated, but heard that the new Ack-on-Error mode might remove the need for Ack-Always. Stay tuned. DB: still unclear about concensus that State Machines should be in the annex (not normative), only the text will be normative. It seems we had a consensus in the room at Montreal, the question is about the concensus of the WG. DB: Pascal says that the WG reached a consensus on this question, but ask for Alex'es opinion. AP: I agree with this point. DB: Could you send a mail stating that the WG reached consensus? DB: Let's get moving... DB: Do you want to discuss the use of aborts in No-ACK or defer it to the ML? PT: let's discuss it now. PT: It has to be clear when to do it and in both sides needs to be done, when to send the aborts needs to be known PT: The state of the sender must be the same as (in perfect agreement with) the receiver. DB: is the current wording (the sener MAY send a sender-abort, the receiver MAY process a sender-abort) appropriate?Do we need to explain the consequences of the receiver not processing a sender-abort? PT: The may implies that you will put the consequences of this may. This the way we write RFC If they use abort both know what is received JCZ: You can send a message or not, but if you send it, the receiver should process it. PT: If you are expecting an abort you need to open your radio.Where both ends recognize this messages. The state gives what is done and not and both sides needs to agree about this and know how to recognize the messages LT: Receiver abort has a high cost in terms of bandwidth and energy (opening the receiver). CG: If we use receiver abort in NO-ACK it will damage the use of this mode JCZ: I agree that the receiver abort is costly, and the sender abort may be send must be processed DB: will implement this decision: Sender-Abort is possible but both ends MUST agree; Receiver-Abort is not allowed. * [17:25] Open window Full proposal - Laurent [15min] LT: This comes from last meeting, about the complete discussion of fragmentation. Having a bigger W field LT: Currently we have a W=1 in ACK-Always without ambiguities because the ACK close the retransmission in each window But this could not be the same in the ACK-on-error mode because there could be an ambiguity to recognise from which window the retransmission is coming from We can extend the W field to have more windows numbered to avoid the retransmission ambiguities. The rest of the header is the same So you compute the number of windows you need to send your complete packet AP: For your calculation you use MTU of 188, 1500b. Are we aiming for this or 1280b is enough? LT: I am considering the worst case - the smallest fragments and the biggest packet and it works LT: You can send the ACK when you want, you do not need to send it at a precise time LT: There is no ambiguity to the window number ER: If we apply this the packet of W=1 and W=2 will be buffered LT: Yes, you need to buffer things in order to be able to compute the MIC ER: You do not have to retransmit W=1 and W=2 fragments after the retransmission of the W=0, this is an additional change from the actual draft LT: Yes JCZ: From the SM that I presented last time, I was assuming that the receiver is always buffering the received frames. But from the transmitter's point of view, I was also suggesting that after the previous window has been correctly received (after restransmissions), the sender would send an empty all-0 to receive an ACK in order to see that the next windows are ok and then sync back to the current window. LT: As ALl-1 must be acknowledged, so we know when we have finished, because this ACK is sent after retransmitting all the windows fragments PT: This comes to my proposal to encode every window AP: Does this proposal solved the issues you have with the ACK-on-error? JCZ: Yes, having the W size variable solves the potential issues I highlighted before. To answer Pascal's point, I see benefit in transmitting ACKs throughout the tranmission so that ACKs are distributed in time. However, if an implementation wants to send a single ACK only at the end, that could be fine as well with the current proposal. It would just need to be specified in the tech-specific profile. PT: We need to be clear what does each part is doing in each side ER: I have the same opinion of JCZ, this complemented ACK solved the problem. PT: Bigger window + FCN is basically a bigger packet number, so in the end we are back to the situation where all the fragments are unambiguasly numbered, because we were not able to live with the situation where the window is just flipping from 0 to 1. Designer's meeting next week same time. Edgar can't make it. We'll take good notes (this time :-) ). Alex not-implemented SCHC rule AP: in case we dont reach an agreement on Ack-on-Error, may appear later. AP: also, anticipate evolutions of SCHC in the future. AP: a schc-minimum draft for every SCHC implementation to agree on a basic set JCZ, PT: not clear what your proposal is. Is it chair-hat off or on? more discussions yet publication deadlines? AP: was chair-hat off. AP: to clarify what I've just said AP: chair hat on : we need to have the draft ready, discussed and agreed upon by the cut-off (October 22nd). AP: chair hat on : if there is not agreement / document is not discussed sufficiently, we'll submit the parts all agree upon (Compression, NO-ACK, ACK-ALWAYS) AP: chair hat off : to address Juanb Carlos' and Edgar's worries that removing ACK-on-Error could lead to interoperability issues down the road, I've described an example proposal to illustrate that it would be trivial to solve such eventual issues. PT: there should not be a situation where both ends don't agree on the rules. We can't afford that (bandwidth, ...) AP: was responding to concerns about interop issues if new frag modes were introduced later down the road. AP: if we agree that both ends should have the same capabilities, there is no need for this not-implemented rule. PT: fundamental difference between SCHC and RoHC: all necessary state/capability is known ahead of time by both ends. PT: we need to bring this to the next meeting and to the ML. to make sure it's vlear and agreed by all. * [17:40] Open discussion on Fragmentation [15min] * [18:00] AOB [ 0min] [18:18] meeting adjourns