Subject: [lp-wan] Proposal: No-ACK, w>1

From: <[email-masked]>
Date: Fri, 20 Jul 2018 14:37:02 +0000

Hello Juan Carlos, WG,

After consulting with the co-authors, it seems there is no issue in relaxing the w=1 recommendation. Also, we could make the "FCN MUST decrement sequentially and MUST start at WIN_MAX_FCN" statement apply to Ack-Always and Ack-on-Error only, so that you are free to use the FCN field pretty much the way you like in No-ACK mode, except for the All-1 value that signals the end of the fragments transmission.
The drawback is a loss of genericity in implementing the various reliability modes. It seems you see an advantage in the change that could offset the drawback. Furthermore, if w==1 in a No-Ack mode implementation,  relaxing the constraint on FCN sequencing is actually a no-change anyway.
How does this look?
WG, any opinions?

Best regards

Dominique

De : Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 18 July 2018 22:59
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, lp-wan <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : RE: WGLC in effect, ending soon! Re: Second last call for SCHC/IP

Hello all,

I took a look at the draft on the Fragmentation section and I’m happy to see that it is getting in a much better shape!

However, I believe that there are still some clarifications and nits that need to be corrected before submitting it for publication.

There are three main points that I summarize here under, followed by suggested text for the draft:

  1.  The SCHC mechanism could be used for transporting non-UDP/IP packets. In this case, if the integrity of the whole fragmented packet can be guaranteed by L2 means, the use of the MIC in the All-1 fragment could sometimes be avoided. If so, the use of the MIC should be made optional, provided there are sufficient L2 means to guarantee the integrity of all the fragments of a packet.
  2.  The No-ACK mode currently states that a one-bit FCN MAY be used. However, the rest of the text assume that this is the only option. It seems like an N>1-bit would be useful to convey some information to the receiver, like for instance the number of fragments in the last window. If this is to be used (optionally), the text should be corrected to allow both options.
  3.  The ACK-on-Error mode has several ambiguities (probably due to some copy-paste errors), and two potential issues. The two issues are that, upon loss of either a single All-0 fragment or a single SCHC ACK, there is no way to recover the session and the whole packet is completely lost. The proposed solution is to allow both sender and receiver to operate on the current and last window. In this way, a SCHC ACK can be sent for the previous window, allowing to recuperate the communication and the lost fragments.

Here are my comments on the draft:

Section 8.5 Baseline Mechanism

  *   Starting from the following paragraph:
     *   The fragmentation functionality uses the FCN value to transmit the SCHC Fragments. It has a length of N bits where the All-1 and All-0 FCN values are used reserved to control the fragmentation transmission. The rest of the FCN numbers MUST be assigned sequentially in a decreasing order, the first FCN of a window is RECOMMENDED to be MAX_WIND_FCN, i.e. the highest possible FCN value depending on the FCN number of bits.
     *   In all modes, the last SCHC Fragment of a packet MUST SHOULD contain a MIC which is used to check if there are errors or missing SCHC Fragments and MUST use the corresponding All-1 fragment format. Note that a SCHC Fragment with an All-0 format is considered the last SCHC Fragment of the current window.
     *   If the receiver receives the last fragment of a SCHC Packet (All-1), it checks for the integrity of the reassembled SCHC Packet, based either on the MIC received or on L2 integrity information. In No-ACK, if the integrity check indicates that the reassembled SCHC Packet does not match the original SCHC Packet (prior to fragmentation), the reassembled SCHC Packet MUST be discarded. In ACK-on-Error or ACK-Always, a MIC check is MAY also performed by the fragment receiver after reception of each subsequent SCHC Fragment retransmitted after the first MIC check.
     *   There are three reliability fragmentation modes of operation: No-ACK, ACK-Always and ACK-on-Error. In ACK-Always and ACK-on-Error, a jumping window protocol uses two windows alternatively, identified as 0 and 1. A non-empty SCHC Fragment with all FCN bits set to 0 (i.e. an All-0 fragment) indicates that the window is over (i.e. the SCHC Fragment is the last one of the window) and allows to switch from one window to the next one. The All-1 FCN in a SCHC Fragment indicates that it is the last fragment of the last window for the whole packet being transmitted and therefore there will not be another window for this packet.

Section 8.5.1 No-ACK

  *   First paragraph:
     *   In the No-ACK mode, there is no feedback communication from the fragment receiver. The sender transmits all the SCHC fragments of a packet without any possibility of knowing if errors or losses have occurred. As in this mode there is no need to identify specific SCHC Fragments, a one-bit FCN MAY be used, in which case . Consequently, the FCN All-0 value would be used in all SCHC fragments except the last one, which carries an All-1 FCN and MAY carry the MIC.
     *   The receiver MAY use the MIC contained in the last SCHC Fragment or some other L2 means to check for errors. When the Inactivity Timer expires or if the MIC integrity check over the set of all received fragments fails indicates that the reassembled packet does not match the original one, the receiver MUST release all resources allocated to reassembling this packet.

Section 8.5.2 ACK-Always

  *   General: For clarity and easier reading, I suggest adding either a subsection or an indented text indicating the “Sender behaviour” and the “Receiver behaviour” before the corresponding text.
  *   Specific changes, starting from first paragraph, last sentences:
  *   (Sender sub-section)
     *   Otherwise, if If FCN reaches 0 and the sender transmits the last SCHC Fragment of the SCHC Packet, the sender uses the All-1 fragment format, which includes MAY include a MIC. The sender sets the Retransmission Timer and waits for the SCHC ACK to know if transmission errors have occurred.
     *   When all missing SCHC Fragments have been retransmitted, the sender starts the Retransmission Timer, even if an All-0 or an All-1 has not been sent as part of this retransmission and waits for a SCHC ACK, (even if an All-0 or an All-1 has not been sent as part of this retransmission).
     *   If an All-0 fragment has been received and all SCHC Fragments of the current window have also been received, the receiver then sends a SCHC ACK, expects a new Window and waits for the next SCHC Fragment.
  *   (Receiver sub-section)
     *   When an All-0 fragment is received, it indicates that all the SCHC Fragments have been sent in the current window. Since the sender is not obliged to always send a full window, some SCHC Fragment number not set in the receiver memory SHOULD not correspond to losses. The receiver sends the corresponding SCHC ACK, the Inactivity Timer is set and, if the SCHC ACK Bitmap indicates that there are no missing fragments, the transmission of the next window by the sender can start.
     *   When an All-1 fragment is received, it indicates that the last SCHC Fragment of the packet has been sent. Since the last window is not always full, the MIC integrity check MAY be used by the receiver to detect if all SCHC Fragments of the packet have been correctly received. A correct MIC integrity check indicates the end of the transmission but the receiver MUST stay alive for an Inactivity Timer period to answer to any potential empty All-1All-0 fragments (i.e. SCHC ACK request message) the sender MAY send if the last SCHC ACKs sent by the receiver is lost. [NOTE: Insert a carriage return] If the MIC integrity check is incorrect, some SCHC Fragments may have been lost. The the receiver MUST send the SCHC ACK indicating the failed integrity check with the C bit, regardless of successful fragmented SCHC Packet reception or not, it MUST set the Inactivity Timer is set. In case of an incorrect MIC, the receiver waits, and it waits for any possible SCHC Fragment retransmissions belonging to the same window. After MAX_ACK_REQUESTS, the receiver will MUST abort the on-going fragmented SCHC Packet transmission by transmitting a the Receiver-Abort format message. The receiver also aborts upon Inactivity Timer expiration by sending a Receiver-Abort message.

Section 8.5.3 ACK-on-Error

  *   General:
     *   For clarity and easier reading, similar to the ACK-Always, I suggest adding either a subsection or an indented text indicating the “Sender behaviour” and the “Receiver behaviour” before the corresponding text.
  *   (Sender sub-section)
  *   Specific changes starting from the first paragraph:
     *   The sender’s behavior for ACK-on-Error and ACK-Always is similar. The main difference is that in ACK-on-Error the SCHC ACK with the encoded Bitmap is not sent at the end of each window but only when expected after sending an All-0 fragment, unless at least one SCHC Fragment of the current windowhas been lost. Except for For the last window,  where after sending the All-1 fragment a SCHC ACK MUST be sent received to finish indicate the end of the transmission.
     *   In ACK-on-Error, the Retransmission Timer expiration is considered as an implicit positive acknowledgement for all windows but the lastone. This timer is set after sending an All-0 or an All-1 fragment. For an All-0 fragment, on timer expiration, the sender resumes operation and sends the SCHC Fragments of the next window.
     *   If the sender receives a SCHC ACK, it checks the window value. The window number on the received Bitmap MAY correspond to the previous or the current window, and therefore the sender MUST keep in memory all fragments from at least both the previous and current windows. The sender verifies which fragments are missing, if these fragments belong to the previous or current window, the counter Attempts is then increased by one and the sender proceeds to retransmission of the missing fragments. Upon retransmission of the requested missing fragments, the Retransmission Timer is started and a SCHC ACK is expected. [NOTE: Insert carriage return] In case there are missing fragments from both previous and current window, the SCHC ACK for the previous window is expected first. In this case, upon correct retransmission and positive SCHC ACK reception of all fragments of the previous window, an empty All-0 fragment for the current window SHOULD be sent triggering a SCHC ACK and inquiring whether there are missing fragments for the current window or not. Upon correct retransmission and positive SCHC ACK reception from the receiver of all fragments of the current window, the transmission of a new window with the ACK-on-Error behaviour continues.
     *   [NOTE: Insert carriage return] When at least one SCHC Fragment has been lost, the counter Attempts is increased by one and the sender resends the missing SCHC Fragments again. When Attempts reaches MAX_ACK_REQUESTS, the sender sends a Sender-Abort message and releases all resources for the ongoing fragmented SCHC Packet transmission. When the retransmission of the missing SCHC Fragments is finished, the sender starts listening for a SCHC ACK (even if an All-0 or an All-1 has not been sent during the retransmission) and initializes the Retransmission Timer.
     *   After sending an the last All-1 fragment, the sender listens for a SCHC ACK, initializes Attempts, and starts the Retransmission Timer. If the Retransmission Timer expires, Attempts is increased by one and an empty All-0 fragment is sent to request again the SCHC ACK for the last window. If Attempts reaches MAX_ACK_REQUESTS, the sender aborts the on-going fragmented SCHC Packet transmission by transmitting the Sender-Abort fragment message. Also, if after sending an All-1 fragment the receiver responds with a SCHC ACK indicating that all fragments have been received but the integrity check has failed, the sender MUST abort the on-going fragmented SCHC Packet transmission and transmit the Sender-Abort message.
     *   At the end of any window, if the sender receives a SCK ACK with a Bitmap containing a bit set for a SCHC Fragment that it has not sent during the transmission phase of that window, it MUST abort the whole fragmentation and transmission of this SCHC Packet.
  *   (Receiver sub-section)
     *   Unlike the sender, the receiver for ACK-on-Error has a larger amount of differences compared with ACK-Always. First, a SCHC ACK is not MUST NOT be sent unless there are is a lost SCHC Fragments or an unexpected behavior. With the exception of An exception to this rule applies to the last window, where a SCHC ACK is always sent MUST always be sent after receiving the All-1 fragment, regardless of SCHC Fragment losses or not. [NOTE: Insert carriage return] The receiver starts by expecting SCHC Fragments from window 0 and maintains the information regarding which SCHC Fragments it receives. After receiving a SCHC Fragment, the Inactivity Timer is set. If no further SCHC Fragment are received and the Inactivity Timer expires, the SCHC Fragment receiver aborts the on-going fragmented SCHC Packet transmission by transmitting the Receiver-Abort data unit message.
     *   Any SCHC Fragment not belonging to the current window is discarded.The actual SCHC Fragment number is computed based on the FCN value. When an All-0 fragment is received and all previous SCHC Fragments have been correctly received, the receiver updates the expected window value and expects a new window (i.e. current window value) and waits for the next SCHC Fragment. If the window value of the next SCHC Fragment has not changed, the received SCHC Fragment is a retransmission. If A receiver thathas already received a Fragment with the same FCN and W bit, it SHOULD discard it. If all SCHC Fragments of a window (that is not the last one) have been received, and the last fragment is an All-0, the receiver does MUST NOT send a SCHC ACK. While the receiver waits for the next window and if the window value is set to the next value, and if an All-1 fragment with the next value window arrived the receiver knows that the last SCHC Fragment of the packet has been sent.
     *   If, after receiving an All-0 fragment the receiver detects that it missed some SCHC Fragments, the receiver MUST send a SCHC ACK with the Bitmap to ask the sender for the retransmission of the missing fragments.
     *   In case the sender unexpectedly continues transmission of the next window, ignoring the SCHC ACK requesting retransmission of some fragments, or omitting the All-0 fragment, it could mean that either the All-0 fragment or the SCHC ACK message was lost. To recover from this situation, the receiver MUST continue receiving fragments from the new current window and upon receiving the All-0 or All-1 fragment from the current window, it MUST send a SCHC ACK with a Bitmap for the previous window. Once the requested fragments for retransmission from the previous window have been correctly received, the receiver MUST send a SCHC ACK with a Bitmap for the previous window indicating the correct reception of all fragments. At this point the receiver SHOULD expect an empty All-0 fragment requesting now a SCHC ACK for the current window. At any moment, if an empty All-0 fragment requesting a SCHC ACK is received, the receiver MUST send the corresponding SCHC ACK with the Bitmap. Once the receiver has received all the missing fragments from the current window it MUST send a final SCHC ACK indicating that all fragments from the current window have been received. At this point, the receiver expects fragments for the next new window and resumes the ACK-on-Error behaviour.
     *   Since the last window is not may not always be always full, the MIC or some other L2 means will be used to detect if all SCHC Fragments of the window have been received. A correct MIC integrity check indicates the successful end of the fragmented SCHC Packet transmission. An , and a SCHC ACK is with the C bit set MUST be sent by the SCHC Fragmentreceiver, indicating the successful reception of the full packet. In case of an incorrect MIC integrity check, the receiver MUST send a SCHC ACK with a Bitmap informing the fragments that have been received, and indicating to the sender with the C bit unset that the integrity check has failed. In case there are missing fragments in the Bitmap, the receiver waits for SCHC Fragments belonging to the same window or the expiration of the Inactivity Timer. The latter expiration of the Inactivity Timer will lead the receiver to abort the on-going SCHC fragmented packet transmission by transmitting the Receiver-Abort message.
     *   If, after receiving an All-0 fragment the receiver missed some SCHC Fragments, the receiver uses a SCHC ACK with the encoded Bitmap to ask the retransmission of the missing fragments and expect to receive SCHC Fragments with the actual window. While waiting the retransmission an All-0 empty fragment is received, the receiver sends again the SCHC ACK with the encoded Bitmap, if the SCHC Fragments received belongs to another window or an All-1 fragment is received, the transmission is aborted by sending a Receiver-Abort fragment. Once it has received all the missing fragments it waits for the next window fragments.

  *   General nits:
     *   Replace “encoded bitmap” by “Bitmap” (several instances)

Regards,

Juan Carlos

From: lp-wan [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: July 16, 2018 12:59 PM
To: lp-wan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [lp-wan] WGLC in effect, ending soon! Re: Second last call for SCHC/IP

Hello WG,

This is a reminder that a Working Group Last Call is on-going for the UDP/IPv6 SCHC draft (draft-ietf-lpwan-ipv6-static-context-hc).
See the draft at https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16

Excerpting from Pascal's mail
>Dear WG,

>  This document has changed to a sufficient degree that I think a 2nd last call is warranted.

>  Emulating what Lou is doing at DetNet, I'd like to start a 3 week LC right ending in our WG session (Thursday July 16th in the morning.)

>  As always, please send LC comment to the list and positive comments, e.g., "I've reviewed this document and believe it is ready for publication", is totally acceptable and most welcome.

>Thank you all again.
>Pascal

The deadline is coming up soon, less than 3 days remaining.
Please voice your opinion as per Pascal's request.
Thank you for your attention

Dominique

De : Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Date : Friday 29 June 2018 05:28
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : Second last call for SCHC/IP
Renvoyer - De : <[email-masked]<mailto:[email-masked]>>
Renvoyer - À : <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Carles Montenegro <[email-masked]<mailto:[email-masked]>>, Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Renvoyer - Date : Friday 29 June 2018 05:28

Dear Authors,

    I started the shepherding process and indeed there were a good number of changes to address carefully the many tickets that we processed.

     We must thank you deeply for the effort but the work is not fully done yet! “Before you submit your draft, it is recommended that you check it for nits using the idnits tool<https://tools.ietf.org/tools/idnits/>.”

    Please fix the easy NITs and republish before Monday: https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lpwan-ipv6-static-context-hc-14.txt

    Other changes needed:

  *   Change to standard track. <rfc category="std" ipr="trust200902" docName="draft-ietf-lpwan-ipv6-static-context-hc-15 "  updates="4944">
  *   Check your references, RFC 2460 is no more needed and a number must move to the Informative reference section (see RFC 3967):

     *   RFC 3385
     *   RFC 4944
     *   RFC 5795
     *   RFC 6936
     *   RFC 7136

  *   Please add a IANA section. It appears that we are not requesting anything from IANA, so the following is sufficient:
                               “
<section title="IANA Considerations">
        <t>This document has no request to IANA. </t>
</section>
          “

  *   Please add a reference to BCP 14; adding the text below in the terminology section  is sufficient
                               “
<section anchor='bcp' title="BCP 14">
<t>

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP 14
    <xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they
    appear in all capitals, as shown here.

</t>
</section> <!-- end section "BCP 14" -->
                        “

Dear WG,

   This document has changed to a sufficient degree that I think a 2nd last call is warranted.

    Emulating what Lou is doing at DetNet, I'd like to start a 3 week LC right ending in our WG session (Thursday July 16th in the morning.)

   As always, please send LC comment to the list and positive comments, e.g., "I've reviewed this document and believe it is ready for publication", is totally acceptable and most welcome.

Thank you all again.

Pascal

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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: Juan Carlos Zuniga <[email-masked]>
Date: Fri, 20 Jul 2018 14:45:30 +0000

Hi Dominique,

From: [email-masked] [mailto:[email-masked]]
Sent: July 20, 2018 10:37 AM
To: Juan Carlos Zuniga <[email-masked]>; lp-wan <[email-masked]>
Cc: [email-masked]
Subject: Proposal: No-ACK, w>1

Hello Juan Carlos, WG,

After consulting with the co-authors, it seems there is no issue in relaxing the w=1 recommendation.
[JCZ] In fact, version 16 already says that it “a one-bit FCN MAY be used”. My proposal was really to clarify the rest of the text and state machine to make it clearer, as the other parts seem to assume that FCN=0 would be used in all fragments (but the last one).
Also, we could make the "FCN MUST decrement sequentially and MUST start at WIN_MAX_FCN" statement apply to Ack-Always and Ack-on-Error only, so that you are free to use the FCN field pretty much the way you like in No-ACK mode, except for the All-1 value that signals the end of the fragments transmission.
The drawback is a loss of genericity in implementing the various reliability modes. It seems you see an advantage in the change that could offset the drawback.
[JCZ] This seems reasonable to me.
Furthermore, if w==1 in a No-Ack mode implementation,  relaxing the constraint on FCN sequencing is actually a no-change anyway.
[JCZ] Indeed.
How does this look?
[JCZ] Fine with me!
WG, any opinions?

Best regards

Dominique

Hello all,

Section 8.5.1 No-ACK

  *   First paragraph:

Section 8.5.2 ACK-Always

  *   (Receiver sub-section)

  *   General:

  *   (Sender sub-section)

  *   (Receiver sub-section)

  *   General nits:

Regards,

Juan Carlos

Hello WG,

Dominique

Dear Authors,

    Other changes needed:

     *   RFC 3385
     *   RFC 4944
     *   RFC 5795
     *   RFC 6936
     *   RFC 7136

</t>

Dear WG,

Thank you all again.

Pascal

Thank you.

Thank you.