Subject: [lp-wan] SCHC fragmentation, ACK-on-Error, seeking comments

From: <[email-masked]>
Date: Fri, 28 Sep 2018 08:37:46 +0000

Hello all,

On Sept 26th, the authors of the ipv6-static-context-hc draft, together with a few contributors, held a design session on the new ACK-on-Error mode of SCHC fragmentation.
This session followed requests and comments issued during IETF102 at Montreal regarding the ACK-on-Error mode, as well as ensuing discussions over the summer.
The session led to a technical proposal.
Here is an update to the Working Group, please read through if you care about SCHC fragmentation.

  *   In the discussed proposal, a major change compared to –16 is that the W field is now wider than just one bit. The aim is to be able to unambiguously identify each window in both the fragments and the ACKs, instead of using only one bit to flip between even and odd windows.
  *   One benefit is to support an easy solution the issue raised by Juan Carlos Zuniga at IETF102 (point 3 in his mail July 18th 22:59 Montreal time).

[In a nutshell, the issue was that, in ACK-on-Error mode, the loss of an All-0 fragment or of an ACK would cause the receiver to still expect fragments from the current window and the sender to advance and send fragments belonging to the next window, which is an error condition at the receiver, leading to an abort. This is not wrong but inefficient. An extension to the same issue is that, if a whole window of fragments goes missing, the receiver will mistake the fragments of a future window as the ones of a past window (odd or even numbers aliasing). Again, the MIC will spot the problem at the very end, leading to an abort. Therefore the behaviour is not wrong, but inefficient.]

  *   The proposal with unambiguous window numbers allows the receiver to request retransmission of missing fragments belonging to windows older than the current one or the last before current. Therefore, it solves the "extended" issue described above, in addition to the original issue.
  *   The proposal with unambiguous window numbers is so powerful that it opens up another degree of freedom: there is no longer a reason why the receiver should even try to send an ACK exactly at the end of each received window that has missing fragments (the end being signalled by the reception of an All-0 fragment or the reception of a fragment with an increased window number). Depending on the technology or other parameters, it might  choose to send the ACKs at some time of its choice after the end of each such received window. Pushing it to the extreme, the receiver might defer sending the ACKs till the very end of the fragmented SCHC Packet transmission (signalled by the reception of the All-1 fragment). Symmetrically, the time at which the sender has to expect a potential ACK does not need to be the end of its transmission of a window. In the extreme example, it would only need to expect the ACKs after it has sent the All-1 fragment.
  *   In the generic SCHC description, relaxing the specification that the receiver MUST send the Acks and the the sender MUST expect Acks at the end of each sent/partly received window has the benefit of fitting each technology better. For example, it allows more freedom for grouping together transmissions or for scheduling receptions.

At the design session on Sept 26th, there was an consensual proposal that

  *   The ipv6-static-context-hc draft will contain normative text that describes Ack-on-Error with the relaxed specification: that's to say, the Acks are sent and expected sometime after the end of the window, but not necessarily immediately after, and not necessarily delaying the transmission of fragments that belong to further windows.
  *   The ipv6-static-context-hc draft will contain in an Appendix non-normative drawings of Ack-on-Error state machines that illustrate one possible algorithm, in which the Acks are sent and expected right after the end of a window, delaying the transmission of fragments that belong to further windows. These drawings do not represent the full range of possibilities allowed by the normative text.
  *   The future LPWAN-technology-specific "SCHC-over-foo" drafts MUST specify when Acks are sent and expected, so that there are no interoperability issues between implementations.

Please provide support or comments to this proposal.
Thanks for having read through!

Dominique, representing the authors and design contributors

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 28 Sep 2018 05:43:34 -0300

I support this proposal.
Regards,

            Diego

El vie., 28 de sep. de 2018 05:38, <[email-masked]> escribió:

> Hello all,
>
> On Sept 26th, the authors of the ipv6-static-context-hc draft, together
> with a few contributors, held a design session on the new ACK-on-Error mode
> of SCHC fragmentation.
> This session followed requests and comments issued during IETF102 at
> Montreal regarding the ACK-on-Error mode, as well as ensuing discussions
> over the summer.
> Here is an update to the Working Group, *please read through if you care
> about SCHC fragmentation.*
>
>    - In the discussed proposal, a major change compared to –16 is that
>    the W field is now wider than just one bit. The aim is to be able to
>    unambiguously identify each window in both the fragments and the ACKs,
>    instead of using only one bit to flip between even and odd windows.
>    - One benefit is to support an easy solution the issue raised by Juan
>    Carlos Zuniga at IETF102 (point 3 in his mail July 18th 22:59 Montreal
>    time).
>
> *[In a nutshell, the issue was that, in ACK-on-Error mode, the loss of an
> All-0 fragment or of an ACK would cause the receiver to still expect
> fragments from the current window and the sender to advance and send
> fragments belonging to the next window, which is an error condition at the
> receiver, leading to an abort. This is not wrong but inefficient. An
> extension to the same issue is that, if a whole window of fragments goes
> missing, the receiver will mistake the fragments of a future window as the
> ones of a past window (odd or even numbers aliasing). Again, the MIC will
> spot the problem at the very end, leading to an abort. Therefore the
> behaviour is not wrong, but inefficient.]*
>
>
>    - The proposal with unambiguous window numbers allows the receiver to
>    request retransmission of missing fragments belonging to windows older than
>    the current one or the last before current. Therefore, it solves the
>    "extended" issue described above, in addition to the original issue.
>    - The proposal with unambiguous window numbers is so powerful that it
>    opens up another degree of freedom: there is no longer a reason why the
>    receiver should even *try* to send an ACK exactly at the end of each
>    received window that has missing fragments (the end being signalled by the
>    reception of an All-0 fragment or the reception of a fragment with an
>    increased window number). Depending on the technology or other parameters,
>    it might  choose to send the ACKs at some time of its choice after the end
>    of each such received window. Pushing it to the extreme, the receiver might
>    defer sending the ACKs till the very end of the fragmented SCHC Packet
>    transmission (signalled by the reception of the All-1 fragment).
>    Symmetrically, the time at which the sender has to expect a potential ACK
>    does not need to be the end of its transmission of a window. In the extreme
>    example, it would only need to expect the ACKs after it has sent the All-1
>    fragment.
>    - In the generic SCHC description, relaxing the specification that the
>    receiver MUST send the Acks and the the sender MUST expect Acks at the end
>    of each sent/partly received window has the benefit of fitting each
>    technology better. For example, it allows more freedom for grouping
>    together transmissions or for scheduling receptions.
>
>    - The ipv6-static-context-hc draft will contain normative text that
>    describes Ack-on-Error with the relaxed specification: that's to say, the
>    Acks are sent and expected sometime after the end of the window, but not
>    necessarily immediately after, and not necessarily delaying the
>    transmission of fragments that belong to further windows.
>    - The ipv6-static-context-hc draft will contain in an Appendix
>    non-normative drawings of Ack-on-Error state machines that illustrate one
>    possible algorithm, in which the Acks are sent and expected right after the
>    end of a window, delaying the transmission of fragments that belong to
>    further windows. These drawings do not represent the full range of
>    possibilities allowed by the normative text.
>    - The future LPWAN-technology-specific "SCHC-over-foo" drafts MUST
>    specify when Acks are sent and expected, so that there are no
>    interoperability issues between implementations.
>
> *Please provide support or comments to this proposal.*
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: arunprabhu kandasamy <[email-masked]>
Date: Fri, 28 Sep 2018 17:27:34 +0200

+1 , for this proposal.

thanks,
Arun

On Fri, Sep 28, 2018 at 10:44 AM Prof. Diego Dujovne <
[email-masked]> wrote:

>>    - In the generic SCHC description, relaxing the specification that
>>    the receiver MUST send the Acks and the the sender MUST expect Acks at the
>>    end of each sent/partly received window has the benefit of fitting each

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Fri, 28 Sep 2018 20:41:15 +0000

Hello all,

As expressed during the call, I support this proposal.

I believe it provides a great degree of freedom that allow optimizing for different technology implementations.

Regarding the non-normative drawings of Ack-on-Error state machines, below are the diagrams that I showed during the call, which depict one possible implementation where Acks can be sent and expected at the end of each window.

The definitions of the different variables/functions are:

cur_W: current (or latest) window

rcv_W: received window from peer

rcv_Bmp: received bitmap from peer

Wn: temporary Window variable

Bitmap: defined by [Window#, Bmp_n]

sync: binary flag to indicate existence of pending unfilled windows

send(): send message

set[]: set value

clear[]: clear variable

MICc: MIC calculation function

Full[]: TRUE if bitmap is full

notFull[]: TRUE if bitmap is not full

oldestW[]: Pointer to oldest unfilled window ID

SENDER

                       +=======+

                       | INIT  |        FCN!=0 & more frags

                       +======++        ~~~~~~~~~~~~~~~~~~~~~~

          Frag RuleID trigger |   +--+  send (cur_W, frag(FCN));

          ~~~~~~~~~~~~~~~~~~~ |   |  |  FCN--;

       cur_W=0; FCN=max_value;|   |  |  set[cur_W, Bmp_n(FCN)];

         clear [cur_W, Bmp_n];|   |  v

    Attempts=0;clear[rcv_Bmp];| ++==+==========+         **BACK_TO_SEND

                              +>+              |     rcv_W==cur_W &

          **BACK_TO_SEND        |     SEND     |     [cur_W,Bmp_n]==rcv_Bmp

    +-------------------------->+              |     & more frags

    |  +----------------------->+              |     ~~~~~~~~~~~~

    |  |                        ++===+=========+     cur_W++;FCN=max_value;

    |  |                         |   |               Attempts=0;

    |  |      FCN==0 & more frags|   |last frag      clear [cur_W, Bmp_n];

    |  |  ~~~~~~~~~~~~~~~~~~~~~~~|   |~~~~~~~~~

    |  |send(cur_W, frag(All-0));|   |set[cur_W, Bmp_n(FCN)];

    |  | set [cur_W, Bmp_n(FCN)];|   |send (cur_W,frag(All-1),MIC);

    |  |       set Retrans_Timer;|   |set Retrans_Timer;

    |  |                         |   | +-----------------------------------+

    |  |Retrans_Timer expires &  |   | |rcv_W==cur_W&[cur_W,Bmp_n]!=rcv_Bmp|

    |  |more Frags               |   | |  ~~~~~~~~~~~~~~~~~~~              |

    |  |~~~~~~~~~~~~~~~~~~~~     |   | |  Attempts++; Wn=cur_W;            |

    |  |stop Retrans_Timer;      |   | | +--------+          rcv_W!=cur_W &|

    |  |cur_W++; FCN=max_value;  v   v | |        v  [rcv_W,Bmp_n]!=rcv_Bmp|

    |  |clear[cur_W, Bmp_n];+====+===+=+=+==+   +=+=========+   ~~~~~~~~~~~|

    |  +--------------------+               |   | Resend    |   Attempts++;|

    +-----------------------+   Wait x ACK  |   | Missing   |     Wn=rcv_W;|

    +---------------------->+               |   | Frags(Wn) +<-------------+

    |                       |               |   +======+====+

    |                       +===+==+==+==+==+          |

    |                           |  |  |  ^             |

    |    Retrans_Timer expires &|  |  |  +-------------+

    |              No more Frags|  |  |     all_missing_frag_sent(Wn)

    |             ~~~~~~~~~~~~~~|  |  |     ~~~~~~~~~~~~~~~~~

    |        stop Retrans_Timer;|  |  |     set Retrans_Timer;

    |                Attempts++;|  |  |

    |  send(cur_W, All-0-empty);|  |  |

    |                           |  |  |

    +---------------------------+  |  |

                      rcv_W==cur_W&|  |

            rcv_Bmp==[cur_W,Bmp_n]&|  | Attempts > MAX_ACK_REQUESTS

        No more Frags & MIC_flag==1|  | ~~~~~~~~~~

                 ~~~~~~~~~~~~~~~~~~|  | send (Abort);

     +=========+stop Retrans_Timer;|  |   +=============+

     |   END   +<------------------+  +-->+ Error/Abort |

     +=========+                         +=============+

RECEIVER

                 +=======+        New frag RuleID received

                 | INIT  |        ~~~~~~~~~~~~~

                 |       +-------+cur_W=0;clear([cur_W,Bmp_n]);

                 +=======+       |sync=TRUE;

                                 |

    Not All* & rcv_W==cur_W+---+ | +---+

      ~~~~~~~~~~~~~~~~~~~~~|   | | |  (C)

     set[cur_W,Bmp_n(FCN)];|   v v v   |

                          ++===+=+=+===+=+

   +----------------------+              +--+ All-0&Full[cur_W,Bmp_n]

   |           ABORT *<---+  Receiving   |  | ~~~~~~~~~~~~~~~~~~~~~~

   |  +-------------------+  new Frags   +<-+ cur_W++;set Inact_timer;

   |  |    All-0-empty +->+=+=+=+=+=+====+    clear[cur_W,Bmp_n];

   |  |        (rcv_W) |    | | ^ | ^

   |  |    ~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W

   |  |sendACK([rcv_W,Bmp_n]);| | | |& Full([cur_W,Bmp_n])

   |  |                       | | | |& All* || last_miss_frag

   |  |                       | | | |~~~~~~~~~~~~~~~~~~~~~~

   |  |    All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]);

   |  |           & sync==TRUE| | | |clear([cur_W,Bmp_n]); cur_W++;

   |  |&notFull([cur_W,Bmp_n])| |(E)|sync=TRUE;

   |  |    ~~~~~~~~~~~~~~~~~~~| | | |              +========+

   |  |sendACK([cur_W,Bmp_n]);| | | |              | Error/ |

   |  |                       | | | |   +----+     | Abort  |

   |  |                       v | v |   |    |     +===+====+

   |  |                   +===+=+=+=+===+=+ (D)        ^

   |  |    All-0-empty +--+    Wait x     |  |         |

   |  |        (rcv_W) +->| Missing Frags |<-+         |

   |  |    ~~~~~~~~~~~    +=============+=+            |

   |  | sendACK([rcv_W,Bmp_n]);            +--------------+

   |  |                                       *ABORT

   v  v

  (A)(B)

                                    (D) All* || last_miss_frag

    (C) rcv_W!=cur_W                    & rcv_W!=cur_W & sync==FALSE

        & sync==TRUE                    & Full([rcv_W,Bmp_n])

        ~~~~~~~~~~~~~~~~~~              ~~~~~~~~~~~~~~~~~~~~

        sync=FALSE; cur_W=rcv_W;        Wn=oldestW[notFull(Bmp_n)];

        set[cur_W,Bmp_n(FCN)];          sendACK([Wn,Bmp_n]);

                              ABORT-->* Inact_Timer expires

                                        || Attempts > MAX_ACK_REQUESTS

    (E) All* & sync==FALSE              ~~~~~~~~~~~~~~~~~~~~~

        ~~~~~~~~~~~~~~~~~~~~            send (Abort);

        Wn=oldestW[notFull(Bmp_n)];

        sendACK([Wn,Bmp_n]);

------------PAGE BREAK-----------

  (A)(B)

   |  | All-1 & rcv_W==cur_W & MICc!=OK

   |  |& notFull([cur_W,Bmp_n])          +-+ All-0 empty(rcv_W)

   |  |~~~~~~~~~~~~~~~~~~~~~~~~~~~~      | | ~~~~~~~~~~

   |  |sendACK([cur_W,Bmp_n],MIC=0);     | v sendACK([rcv_W,Bmp_n]);

   |  |                      +===========+=++

   |  +--------------------->+   Wait End   +-+

   |                         +=====+=+=+==+=+ | All-1

   |                               | | |  ^   | & rcv_W==cur_W

   |        rcv_W==cur_W & MICc==OK| | |  |   | & MICc!=OK

   |         ~~~~~~~~~~~~~~~~~~~~~~| | |  +---+ &notFull([cur_W,Bmp_n])

   |  sendACK([cur_W,Bmp_n],MIC=1);| | |        ~~~~~~~~~~~~~~~~~~~~~~

   |                               | | |  sendACK([cur_W,Bmp_n],MIC=0);

   |                               | | |        Attempts++;

   |All-1 & Full([cur_W,Bmp_n])    | | |

   |& MICc==OK & sync==TRUE        | | +-->* ABORT

   |~~~~~~~~~~~~~~~~~~~            | |

   |sendACK([cur_W,Bmp_n],MIC=1);  | |All-1 & rcv_W==cur_W & MICc!=OK

   |                               | |& Full([cur_W,Bmp_n])

   |                               | |~~~~~~~~~~~~~~~~~~~~~

   |         +===========+         | |send (Abort);

   +-------->+    END    +<--------+ |

             +===========+           |     +=============+

                                     +---->+ Error/Abort |

                                           +=============+

         ABORT -->* Inact_Timer expires

                    || Attempts > MAX_ACK_REQUESTS

                    ~~~~~~~~~~~~~~~~~~~~~

                    send (Abort);

Best,

Juan Carlos

From: lp-wan <[email-masked]> On Behalf Of [email-masked]
Sent: September 28, 2018 4:38 AM
To: lp-wan <[email-masked]>
Subject: [lp-wan] SCHC fragmentation, ACK-on-Error, seeking comments

Hello all,

Thank you.