Connection details ------------------ * Date: September 5th 2018 * Time: 8-9AM DST, 17:00 CEST: https://www.worldtimebuddy.com/?qm=1&lid=2988507,1816670,5391959,5128581&h=2988507&date=2018-09-05&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 IETF 102 - Dominque [10min] * [17:20] ACK-on-Error - Juan Carlos, Carles, Edgar [30min] * [17:50] Discussion [10min] * [18:00] AOB 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 Past Attendees --------- Action Items from last time ---------------------------- * Chairs: find reviewers for drafts Agenda ------ * [17:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts * [17:10] SCHC Updates since IETF 102 - Dominque [10min] * [17:20] ACK-on-Error - Juan Carlos, Carles, Edgar [30min] * [17:50] Discussion [10min] * [18:00] AOB [ 0min] Minutes ------ * [17:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts * Alex: Reads the Note Well * The agenda is accepted nothing to add, the SCHC compression part is accepted and will not change * SM in the appendix and the text normative for the fragmentation part (to be confirmed on the ML) * SM in normative part could be trouble for adoption by other groups, so keep it in appendix * Discussion about the ACK-on-Error problematic: there are 3 possibilities * first keep it as it is * second a big modification and move it to a different document * third minor modification but need to understand consequences * We need some studies to see the possible modifications and how they affect the other uses cases * [17:10] SCHC Updates since IETF 102 - Dominque [10min] * Dominique * This is only editorial (no protocol changes) - all changes are on the github * * Processing the Charlie Perkins reviews, except section 8 that need to be written again * Dominique has sent some questions to finished all the process * Edgar input to modify the term L2 Data Unit usage and align with the Technology specific terminology * restructure * Appendix D has been restructure to be better understandable in order to use only what is needed: if F/R is not used, one should not have to specify F/R-related parameters! * Section 8 has been restructure to separate the description of the messages, the header, the timers, the counter from the algorithmic specification of the F/R/ modes. * Need to be done: fill the No-Ack and Ack-Always sections for Ack-on-Error will be finished after all the discussion and modifications are done. * 7 points with Charlie and doble check the SM and appendix * Swift publication to version 17. * [17:20] ACK-on-Error - Juan Carlos, Carles, Edgar [30min] * Juan Carlos takes the ball * look in the details of ack on error as is * consider minimal changes * Dominique's changes help a lot already * Carles takes the ball * Analysis of the issue presented by Juan Carlos. Look at probability, and to what extent it can be mitigated * Figure is presented (slide 18). scenario is we do not get the SCHC ACK on error, any of the 2 red crosses on slide 19. Receiver sends an abort if the next window starts though an ack on error was sent * Juan Carlos suggests to send the SCHC ack again, and fi the first window first * presenting basic maths to see the chances of issue. usus uncorrelated loss to make the problem tractable Note: problem will not happen with single window since the ack at the end is like ack always. * The proposal improves the situation but does not remove it, illustrated in slides 21 22. * Alex: The issue you mention is that you have a packet lost * slide 24: smaller window size augment the chances of occurences * Alex: you need to lose a first fragment otherwise there is not error the trigger ack on error * Edgar: repeating the last message to reduce the chances of loss has a cost. * Dominique at some point ack always has no worst overhead. We has this proposal to switch mode dynamically. * [17:50] Discussion [10min] * Juan Carlos: Look at impact to state machine. We want to keep the same number of states. Showing new state machine slide 27. New transitions but same number of states. Things where missing in the original SM were fixed here as much as possible. * slide 28. Laurent: what is C1 and C2? * Juan Carlos: they are transition C, but there are really 2 cases now. * Edgard on alt solution slide 31 * Can we go farther than 2 windows? Proposal is to ack witha an absolute count packets. xmit vs. transmitted fragments. * interoperability could be an issue * Alex: message format with version we can know it is an abort * Pascal: I read that as abandon bitmap for ack on error * Alex: mean one error message per miss * Laurent: This is an extension of what we have done? Now the window is 1 bit, we can extend the window to several bits. We can number windows 0, 1, 2, 3 for smaller bitmaps; A bitmap will carry window number/bitmap. This way we limit the size of the bitmap. * Juan Carlos: You do not know if there is many errors * Edgar for NBioT it could happen for the last packet, switching modes would happen in the core network. There is a problem with the switching solution. * Edgar we need to consider all the solution and find the good one * JCZ all the solutions are based on the ACK-on-error (dont send ACK if you dont need to, but when there are errors you still want to recover) but perhaps a new mode could be better * Pascal: it is better to have only 1 window because having more than one may have a lot of troubles * Edgar: this is perhaps the conclusion of this study. Considering a use-case for SCHC: Ethernet over 5G! * Laurent: it may be a technology depending * Alex: very interesting alternatives. At some point in time, we were considering having only Ack-Always in this draft and give more time to design Ack-on-Error. * Alex: Split the ACK-on-Error to a new document without leaving the basic one we have produced. * Edgar: seems like this is the work that JCZ did, figure the right parameters. * JCZ: would not like to see fragmentation in multiple draft. * Dominique: with the new structure of the F/R section, it's easy to leave subsection 8.3 empty (or remove it) and have a separate draft specify this mode, using the same * Pascal: we need to finish this meeting, we seems to be in a loop, there is a problem there are some propositions (JCZ and Edgar) then we come back to the basic one. * Laurent: With a mix with the windows and the bitmap you have something new, but Edgar is different * [18:00] AOB Minutes -------