Minutes interim-2018-lpwan-11: Wed 17:00
minutes-interim-2018-lpwan-11-201809191700-01

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