Subject: [lp-wan] WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Jul 2018 14:31:01 +0000

Dear authors :

Many thanks for addressing all WGLC comments and posting before cut off.

Please find below my shepherd review on draft 16:

Overall: I have reviewed this document and believe it is ready for publication. I find it very clear and highly readable; the examples and FSM in appendix are really useful.
Many thanks to all the authors for the excellent work!

Comments:

There are 3 tickets left to be closed, 15, 30 and 31 but I understand that they are fully addressed. They need to be closed.

P 34 on abort:
"

   Since an All-1 fragment MIC MUST be at least the size of an L2 Word,

   a receiver can distinguish a Sender-Abort from an All-1 fragment,

   even in the presence of padding.
"
How do we distinguish from an All-1 empty fragment? Maybe we can live without the All-1 Empty, just resend the full All-1 in case that is what was lost?

In always ack mode:
"

                                             Since the sender is

   not obliged to always send a full window, some SCHC Fragment number

   not set in the receiver memory may not correspond to losses.

"
And
"

   On the other hand, if the window value of the next received SCHC

   Fragment is set to the next expected window value, this means that

   the sender has received a correct encoded Bitmap reporting that all

   SCHC Fragments have been received.

"
This indicates that the receiver does not know if it has received a full window and the sender indicates that it's done. Yet later:
"
          If all the bits of the Bitmap are set to one, the receiver
   MUST send a SCHC ACK without waiting for an All-0 fragment and the
   Inactivity Timer is initialized.

"
Expects the receiver to recognize a full window, and this is what triggers the ACK in a case of a retransmission. Also:
"
   Upon
   receipt of the SCHC ACK, if one or more SCHC Fragments have not yet
   been received, the counter Attempts is increased and the sender
   resends the missing SCHC Fragments again.

"
Indicates that there is no All-x at the end of a retransmission, so the receiver decides when to send an ack.
This appears inconsistent.

The same goes in Ack on error mode

"
   When an All-0 fragment is received and all SCHC Fragments have been
   received, the receiver updates the expected window value and expects
   a new window and waits for the next SCHC Fragment.

"
We do not know that all fragments have been received; we just observe that the sender goes to W=1-W; the thing is, how do we detect an error so we can send an ack on error?

Seems to me that the window MUST always start at 2N-2 and the last window (which may be the first) MAY end before FCN reaches zero.

Nits:

"
   o  Abort.  A SCHC Fragment format to signal the other end-point that
      the on-going fragment transmission is stopped and finished.

"

>        What is stopped in not one fragment but the whole fragmented packet
"

   o  Abort.  A SCHC Fragment format to signal the other end-point that

      the on-going transmission of a fragmented packet is interrupted and

      will not continue.
"

"

   o  C: Checked bit.  Used in an acknowledgement (SCHC ACK) header to

      determine if the MIC locally computed by the receiver matches (1)

      the received MIC or not (0).

"

Ø  The values  do not read naturally in the sentence

"

   o  C: Checked bit.  Used in an acknowledgement (SCHC ACK) header. Set

      (to 1) if the MIC locally computed by the receiver matches the MIC

      received with the acknowledged All-1 fragment, and reset (to 0) if

      it does not.

"

"

   o  Dev: Device.  A node connected to an LPWAN.  A Dev SHOULD

      implement SCHC.

"

Ø  The SHOULD might not be appropriate, it is hard to specify that all LPWAN devices support SCHC.
"

   o  Dev: SCHC Device.  A node that uses SCHC to transmit over an LPWAN.
"

"

   o  W: Window bit.  A SCHC Fragment header field used in ACK-on-Error

      or ACK-Always mode Section 8<https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>, which carries the same value for all

      SCHC Fragments of a window.
"

Ø  Need to indicate that it is flipped at each window

"

   o  W: Window bit.  A SCHC Fragment header field used in ACK-on-Error

      or ACK-Always mode Section 8<https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>, which carries the same value for all

      SCHC Fragments of a window, and is flipped between adjacent windows.
"

"

                                                          Both the Rule

   ID and the Compression Residue potentially have a variable size, and

   generally are not a mutiple of bytes in size.

"

Ø  Typo on multiple, may be reworded
"

                                                          Both the Rule

   ID and the Compression Residue potentially have a variable size, and

   are not necessarily aligned to an octet.

"

"

         compressed header (with possibly a Compression Residue) SHOULD

         be obtained.  Otherwise, the next Rule is tested.
"

Ø  Not a proper use for uppercase SHOULD. What else could happen?
"

         compressed header (with possibly a Compression Residue) is

         obtained.  Otherwise, the next Rule is tested.

"

"

   Compression is done in order that Fields Descriptions appear in a

   Rule.

"

Ø  This reads wrong. 'In order that' seems to say 'so that'
"

   Compression is done in the order that Fields Descriptions appear in a

   Rule.
"

"
                                                     (Example for N=5,
      MAX_WIND_FCN MAY be set to 23, then subsequent FCNs are set
      sequentially and in decreasing order, and the FCN will wrap from 0
      back to 23).

"
Not sure if the MAY is really useful. In any case, what's important Is that 23 is the maximum
"
                                     (Example for N=5, MAX_WIND_FCN MUST
      be lower or equal to 23, then subsequent FCNs are set
      sequentially and in decreasing order, and the FCN will wrap from 0
      back to MAX_WIND_FCN).

"

"

  transmitted, which MAY be especially beneficial in asymmetric
      scenarios.

"
MAY is not appropriate
"
   transmitted, which is especially beneficial in asymmetric
      scenarios.

"

"
   The Rule ID and Dtag values in the SCHC ACK messages MUST be
   identical to the ones used in the SCHC Fragments that are being
   acknowledged.  This allows matching the SCHC ACK and the
   corresponding SCHC Fragments.

"
The Window bit must match as well:

"   The values of the Rule ID, the W bit, and the Dtag in the SCHC ACK messages MUST be
   identical to the ones used in the SCHC Fragments that are being
   acknowledged.  This allows matching the SCHC ACK and the
   corresponding SCHC Fragments.

"
Should we clarify that in case of mismatch the transmission of the packet is aborted?

"
   The Rule ID and Dtag values in the Receive-Abort message MUST be
   identical to the ones used in the fragments of the SCHC Packet the
   transmission of which is being aborted.

"
Though it is quite clear that this is true for both sender AND receiver abort, this is said only for the receiver...

"

   Then, the fragment receiver MAY determine the SCHC Fragment
   reliability mode that is used for this SCHC Fragment based on the
   Rule ID in that fragment

"
No need for MAY (there are others next that you might want to replace too)

"

   Then, the fragment receiver determines the SCHC Fragment
   reliability mode that is used for this SCHC Fragment based on the
   Rule ID in that fragment

"

"

If the sender receives a SCK ACK

"
typo

"

If the sender receives a SCHC ACK

"

Again, occurrences of " MAY " that are now warranted in 8.6.  Supporting multiple window sizes

"
   The default initial value for the Inactivity timer, as well as the
   maximum number of retries for a specific SCHC ACK, denoted
   MAX_ACK_RETRIES, are not defined in this document, and need to be
   defined in other documents (e.g. technology-specific profiles).

"
In other places, it is said that these MUST be defined in technology specific documents. This should be the same

Fig 27 does not indicate padding for the ack, though it could be needed there too

10.6.  Hop Limit field

For DL, MO could be ignore and CDA could be not-sent; DL=1 would be assumed on receive.

"

   The UDP checksum operation is mandatory with IPv6 [RFC8200<https://tools.ietf.org/html/rfc8200>] for most

   packets but recognizes that there are exceptions to that default

   behavior.
"
Missing something in the sentence
"

   The UDP checksum operation is mandatory with IPv6 [RFC8200<https://tools.ietf.org/html/rfc8200>] for most

   packets but the specification recognizes that there are exceptions

   to that default behavior.
"

Cheers,

Pascal

---

From: <[email-masked]>
Date: Wed, 4 Jul 2018 05:44:20 +0000

Hello Pascal,

Thanks for your thorough review and your comments.
See some responses inline
Best regards

Dominique

De : Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 3 July 2018 16:31
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16
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 : Tuesday 3 July 2018 16:31

Dear authors :

Comments:

P 34 on abort:
“

   even in the presence of padding.
“
How do we distinguish from an All-1 empty fragment? Maybe we can live without the All-1 Empty, just resend the full All-1 in case that is what was lost?
[DB] the All-1 fragment, All-1 empty fragment and Send-Abort are distinguishable based on their length.
  The All-1 fragment has MIC and payload, MIC is at least the size of an L2 Word. Paylaod is at least the size of an L2 Word.
  The All-1 fragment has MIC and no payload.
  Sender-Abort has neither MIC nor payload.
  So, all 3 are distinguishable, even in the presence of padding, which is always less than an L2 Word.

In always ack mode:
“

                                             Since the sender is

“
And
“

“
This indicates that the receiver does not know if it has received a full window and the sender indicates that it’s done. Yet later:
“
          If all the bits of the Bitmap are set to one, the receiver
   MUST send a SCHC ACK without waiting for an All-0 fragment and the
   Inactivity Timer is initialized.

“
“

“
Indicates that there is no All-x at the end of a retransmission, so the receiver decides when to send an ack.
This appears inconsistent.
[DB] maybe we are not accurate enough in the text with the use of a "full" window.
The general idea is that the sender may not use all FCN values, and therefore it may be done sending the window without all the bits in the receiver bitmap being 1's.
This is correctly captured in your third quote is a termination condition when there are repetition. If the receiver bitmap gets full of 1's, the receiver has no benefit of waiting any further and can send the SCHC ACK.
As a consequence, the sender does not need to re-transmit the All-x fragment after repeating some intermediates fragments that were reported missing. This is captured in your fourth quote.

“

“
We do not know that all fragments have been received; we just observe that the sender goes to W=1-W; the thing is, how do we detect an error so we can send an ack on error?
[DB] if fragments will all FCN values were correctly received, we know that all fragments have been received. If they are missing FCN values when the All-0 is received, we don't know.
  I'll leave it to the other authors to complement my response, but some more guesswork can be done. If the missing FCN are not exactly a contiguous sequence ending at 1, we know some fragments went missing.
  I'd say an implementation could send a SCH ACK whenever there are missing FCN values (missing bits in the local bitmap). This is correct behaviour, even though it might be overly pessimistic.

Seems to me that the window MUST always start at 2N-2 and the last window (which may be the first) MAY end before FCN reaches zero.
[DB] true, this is indeed what is specified. Except it's MAX_WIND_FCN, not necessarily 2^N-2.

Nits:
[DB] thanks. We'll take care of them

“

“

>        What is stopped in not one fragment but the whole fragmented packet
“

      will not continue.
“

“

“

“

      it does not.

“

“

      implement SCHC.

“

“

“

“

“

“

“

“

                                                          Both the Rule

“

“

                                                          Both the Rule

“

“

“

“

“

“

   Rule.

“

Ø  This reads wrong. ‘In order that’ seems to say ’so that’
“

   Rule.
“

“
                                                     (Example for N=5,

“
Not sure if the MAY is really useful. In any case, what’s important Is that 23 is the maximum
“
                                     (Example for N=5, MAX_WIND_FCN MUST
      be lower or equal to 23, then subsequent FCNs are set
      sequentially and in decreasing order, and the FCN will wrap from 0
      back to MAX_WIND_FCN).

“

“

“
MAY is not appropriate
“

“

“

”

“   The values of the Rule ID, the W bit, and the Dtag in the SCHC ACK messages MUST be
   identical to the ones used in the SCHC Fragments that are being
   acknowledged.  This allows matching the SCHC ACK and the
   corresponding SCHC Fragments.

“

“

“
Though it is quite clear that this is true for both sender AND receiver abort, this is said only for the receiver…

“

“

“

“

“

“
typo

“

“

Again, occurrences of “ MAY “ that are now warranted in 8.6.  Supporting multiple window sizes

“

“

10.6.  Hop Limit field

“

   behavior.
“
“

“

Cheers,

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.

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 01:51:38 +0000

WG,

Following a discussion with Pascal and Laurent last week-end, I would like to bring the following to your attention.

What is it about?
This is about SCHC fragmentation.
More specifically, this is about fragmentation in Ack-Always or Ack-on-Error modes, where fragments are sent clustered together in windows, after which a SCHC ACK is expected by the fragment sender from the fragment receiver.
Within a window, the successive fragments are numbered with a Fragment Compressed Number (FCN).
The draft mandates that the first fragment in a window is numbered with FCN = MAX_WIND_FCN.
The draft mandates that successive fragments are allocated contiguously decreasing FCN values and/but the last fragment in a window has an FCN of 0 (resp. 2^N-1) if the window is not the last one (resp. is the last one) of the SCHC packet.

Current situation
The intention was to leave it open for a window to carry a number of fragments less that MAX_WIND_FCN+1.
This can be obtained by sending fragments in a contiguously decreasing sequence of FCN values finishing at a value different from 1, and jumping to 0 (resp. 2ˆN –1) for the last fragment.
For example : a 4,3,2,0 sequence is meant to be legal.
This results, in certain situations, in the receiver not being able to decide on its own if it has received all the fragments.
This in turn results in extra delay and/or round-trip before being able to advance to the next window, in certain situations.
This also results in a hazier description of the algorithm, which impedes understanding.

Proposed change
We are proposing to change the specification to mandate that all windows but the last one have exactly MAX_WIND_FCN+1 fragments.
They would be numbered from MAX_WIND_FCN downto 0 in a contiguous and complete sequence.
As a consequence, the receiver, upon receiving an FCN==0 fragment, immediately knows by itself if it has received all the fragments of that window.
In turn, the algorithm becomes simpler to explain and some timeouts and/or round/trip can be avoided.
However, some flexibility is sacrificed.

What should you do?
We're going to discuss this point at the WG meeting on Thursday.
I wanted to give you a heads-up, so you can think about it ahead of time.
Even better, if you already have an opinion on this, can you please voice it on the mailing list so that we get an early sense?
This could take such form as
"I don't see a use for partially filled fragmentation windows and I support the simplification brought about by mandating that all windows (but the last one) be full."
Or
"I have a case where being able to send incomplete windows is a strong benefit and I object to mandating that they be full."

Thanks

Dominique

De : Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 4 July 2018 01:44
À : Pascal Thubert <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : Re: WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16
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 : Wednesday 4 July 2018 01:44

Hello Pascal,

Dominique

Dear authors :

Comments:

P 34 on abort:
“

In always ack mode:
“

                                             Since the sender is

“
And
“

“

“

“

“

“

Nits:

“

“

“

      will not continue.
“

“

“

“

      it does not.

“

“

      implement SCHC.

“

“

“

“

                                                          Both the Rule

“

                                                          Both the Rule

“

“

“

“

   Rule.

“

   Rule.
“

“
                                                     (Example for N=5,

“

“

“

“
MAY is not appropriate
“

“

“

”

“

“

“

“

“

“

“

“

“
typo

“

“

“

“

10.6.  Hop Limit field

“

   behavior.
“

Cheers,

Pascal

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 17 Jul 2018 16:04:54 +0900

Hi Dominique,

Could you give an example when the FCN sequence is like a 4,3,2,0 ?  (I think that it's more likely 6 5 4 3 2 0 by the way)

Thanks,
Shoichi

On 7/17/18 10:51, [email-masked] wrote:
> *What is it about?*
> *Current situation*
> *Proposed change*
> *What should you do?*
> De : Dominique Barthel <[email-masked] <mailto:[email-masked]>>
> À : Pascal Thubert <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc : lp-wan <[email-masked] <mailto:[email-masked]>>
> 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]>>
> De : Pascal Thubert <[email-masked] <mailto:[email-masked]>>
> À : "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc : lp-wan <[email-masked] <mailto:[email-masked]>>
> 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]>>
> _Comments:_
> _Nits:_
>       or ACK-Always mode Section 8 <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>, which carries the same value for all
> 
>       or ACK-Always mode Section 8 <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>, which carries the same value for all
> 
>    The UDP checksum operation is mandatory with IPv6 [RFC8200 <https://tools.ietf.org/html/rfc8200>] for most
> 
>    The UDP checksum operation is mandatory with IPv6 [RFC8200 <https://tools.ietf.org/html/rfc8200>] for most
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 17 Jul 2018 08:08:59 -0400

If the FCN size is 3 then now the only possible sequence is

6 5 4 3 2 1 0
6 5 4 3 2 1 0

and for the last one (all-1 window) starting at any number, for instance :

3 2 1 7

which was a recommanded behavior, and becomes the imposed one.

For instance;

6 4 2 0

which is now allowed by the document will not be legal.

Laurent

On Tue, Jul 17, 2018 at 3:05 AM Shoichi Sakane <[email-masked]> wrote:

> Hi Dominique,
>
> Could you give an example when the FCN sequence is like a 4,3,2,0 ?  (I
> think that it's more likely 6 5 4 3 2 0 by the way)
>
> Thanks,
> Shoichi
>
>
> > Following a discussion with Pascal and Laurent last week-end, I would
> like to bring the following to your attention.
> >
> > *What is it about?*
> > More specifically, this is about fragmentation in Ack-Always or
> Ack-on-Error modes, where fragments are sent clustered together in windows,
> after which a SCHC ACK is expected by the fragment sender from the fragment
> receiver.
> > The draft mandates that successive fragments are allocated contiguously
> decreasing FCN values and/but the last fragment in a window has an FCN of 0
> (resp. 2^N-1) if the window is not the last one (resp. is the last one) of
> the SCHC packet.
> >
> > *Current situation*
> > This can be obtained by sending fragments in a contiguously decreasing
> sequence of FCN values finishing at a value different from 1, and jumping
> to 0 (resp. 2ˆN –1) for the last fragment.
> > This results, in certain situations, in the receiver not being able to
> decide on its own if it has received all the fragments.
> > This in turn results in extra delay and/or round-trip before being able
> to advance to the next window, in certain situations.
> > We are proposing to change the specification to mandate that all windows
> but the last one have exactly MAX_WIND_FCN+1 fragments.
> > As a consequence, the receiver, upon receiving an FCN==0 fragment,
> immediately knows by itself if it has received all the fragments of that
> window.
> > Even better, if you already have an opinion on this, can you please
> voice it on the mailing list so that we get an early sense?
> > "I don't see a use for partially filled fragmentation windows and I
> support the simplification brought about by mandating that all windows (but
> the last one) be full."
> > Or
> > "I have a case where being able to send incomplete windows is a strong
> benefit and I object to mandating that they be full."
> >
> > Thanks
> >
> > Dominique
> >
> > À : Pascal Thubert <[email-masked] <mailto:[email-masked]>>, "
> [email-masked] <mailto:
> [email-masked]>" <
> [email-masked] <mailto:
> [email-masked]>>
> > Objet : Re: WGLC-2; shepherd review of
> draft-ietf-lpwan-ipv6-static-context-hc-16
> > 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]
> >>
> > À : "[email-masked] <mailto:
> [email-masked]>" <
> [email-masked] <mailto:
> [email-masked]>>
> > Objet : WGLC-2; shepherd review of
> draft-ietf-lpwan-ipv6-static-context-hc-16
> > 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]
> >>
> > Overall: I have reviewed this document and believe it is ready for
> publication. I find it very clear and highly readable; the examples and FSM
> in appendix are really useful.
> >
> > There are 3 tickets left to be closed, 15, 30 and 31 but I understand
> that they are fully addressed. They need to be closed.
> >
> >
> >
> > P 34 on abort:
> >
> > “
> >
> >
> >
> > How do we distinguish from an All-1 empty fragment? Maybe we can live
> without the All-1 Empty, just resend the full All-1 in case that is what
> was lost?
> >
> >   The All-1 fragment has MIC and payload, MIC is at least the size of an
> L2 Word. Paylaod is at least the size of an L2 Word.
> > This indicates that the receiver does not know if it has received a full
> window and the sender indicates that it’s done. Yet later:
> >
> > “
> >
> > Expects the receiver to recognize a full window, and this is what
> triggers the ACK in a case of a retransmission. Also:
> >
> > “
> >
> >    Upon
> >
> > The general idea is that the sender may not use all FCN values, and
> therefore it may be done sending the window without all the bits in the
> receiver bitmap being 1's.
> > This is correctly captured in your third quote is a termination
> condition when there are repetition. If the receiver bitmap gets full of
> 1's, the receiver has no benefit of waiting any further and can send the
> SCHC ACK.
> > As a consequence, the sender does not need to re-transmit the All-x
> fragment after repeating some intermediates fragments that were reported
> missing. This is captured in your fourth quote.
> >
> >
> >
> > We do not know that all fragments have been received; we just observe
> that the sender goes to W=1-W; the thing is, how do we detect an error so
> we can send an ack on error?
> >
> > [DB] if fragments will all FCN values were correctly received, we know
> that all fragments have been received. If they are missing FCN values when
> the All-0 is received, we don't know.
> >
> >   I'll leave it to the other authors to complement my response, but some
> more guesswork can be done. If the missing FCN are not exactly a contiguous
> sequence ending at 1, we know some fragments went missing.
> >
> >   I'd say an implementation could send a SCH ACK whenever there are
> missing FCN values (missing bits in the local bitmap). This is correct
> behaviour, even though it might be overly pessimistic.
> >
> >
> >
> >
> > Seems to me that the window MUST always start at 2N-2 and the last
> window (which may be the first) MAY end before FCN reaches zero.
> >
> >       or ACK-Always mode Section 8 <
> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>,
> which carries the same value for all
> >
> >       or ACK-Always mode Section 8 <
> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>,
> which carries the same value for all
> >
> > Though it is quite clear that this is true for both sender AND receiver
> abort, this is said only for the receiver…
> >
> >
> >
> >
> >
> > “
> >
> > In other places, it is said that these MUST be defined in technology
> specific documents. This should be the same
> >
> >
> >
> >
> >
> >    The UDP checksum operation is mandatory with IPv6 [RFC8200 <
> https://tools.ietf.org/html/rfc8200>] for most
> >
> >    The UDP checksum operation is mandatory with IPv6 [RFC8200 <
> https://tools.ietf.org/html/rfc8200>] for most
> >
> > 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,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> > 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,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Jul 2018 12:55:20 +0000

I’m all for that change... reason is it makes behavior a lot easier to understand.

There’s a corollary chance on the text that say to drop packets from the wrong window. It must be clear that, even with the new rule:

Sending a ack, the receiver does not know what the right window is for the next packet. Depends whether the sender gets the ack or not. So the receiver can not drop anything after sending an ack till it sees what window the sender now uses.

Which is a good reason why we do not support fragments out of order...

Regards,

Pascal

Le 17 juil. 2018 à 08:10, Laurent Toutain <[email-masked]<mailto:[email-masked]>> a écrit :

6 5 4 3 2 1 0
6 5 4 3 2 1 0

3 2 1 7

For instance;

6 4 2 0

Laurent

On Tue, Jul 17, 2018 at 3:05 AM Shoichi Sakane <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dominique,

Thanks,
Shoichi

On 7/17/18 10:51, [email-masked]<mailto:[email-masked]> wrote:
> De : Dominique Barthel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> À : Pascal Thubert <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> Cc : lp-wan <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> Renvoyer - De : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> Renvoyer - À : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, Carles Montenegro <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, Dominique Barthel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> De : Pascal Thubert <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> À : "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> Cc : lp-wan <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> Renvoyer - De : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> Renvoyer - À : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, Carles Montenegro <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, Dominique Barthel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>   I'll leave it to the other authors to complement my response, but some more guesswork can be done. If the missing FCN are not exactly a contiguous sequence ending at 1, we know some fragments went missing..
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan
_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Nicolas Sornin <[email-masked]>
Date: Tue, 17 Jul 2018 13:12:26 +0000

I was actually assuming what you are describing would be the rule, and at least this is how we are implementing it.
I am also in favour of this change, lot clearer.
I cannot see any use case where we would want to use non-contiguous fragment counter values.

From: lp-wan <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, July 17, 2018 2:55 PM
To: Laurent Toutain <[email-masked]>
Cc: Shoichi Sakane <[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16

WARNING - External Email
________________________________
I’m all for that change... reason is it makes behavior a lot easier to understand.

Regards,

Pascal

6 5 4 3 2 1 0
6 5 4 3 2 1 0

3 2 1 7

For instance;

6 4 2 0

Laurent

Thanks,
Shoichi

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 17 Jul 2018 15:18:06 +0200

+1

With this change, we gain clarity, avoid unnecessary complexity and avoid
potentially unnecessary overhead.

Carles

> There’s a corollary chance on the text that say to drop packets from the
> wrong window. It must be clear that, even with the new rule:
>
> Sending a ack, the receiver does not know what the right window is for the
> next packet. Depends whether the sender gets the ack or not. So the
> receiver can not drop anything after sending an ack till it sees what
> window the sender now uses.
>
> Le 17 juil. 2018 à 08:10, Laurent Toutain
> <[email-masked]<mailto:[email-masked]>>
> a écrit :
>
> On Tue, Jul 17, 2018 at 3:05 AM Shoichi Sakane
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Dominique,
>
> On 7/17/18 10:51,
> [email-masked]<mailto:[email-masked]> wrote:
>> WG,
>>
>> Ack-on-Error modes, where fragments are sent clustered together in
>> windows, after which a SCHC ACK is expected by the fragment sender from
>> the fragment receiver.
>> decreasing FCN values and/but the last fragment in a window has an FCN
>> of 0 (resp. 2^N-1) if the window is not the last one (resp. is the last
>> one) of the SCHC packet.
>>
>> *Current situation*
>> sequence of FCN values finishing at a value different from 1, and
>> jumping to 0 (resp. 2ˆN –1) for the last fragment.
>> support the simplification brought about by mandating that all windows
>> (but the last one) be full."
>> Or
>> De : Dominique Barthel
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> À : Pascal Thubert <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>,
>> "[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>"
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> Cc : lp-wan <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> Renvoyer - De : <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> Renvoyer - À : <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>,
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>,
>> Carles Montenegro <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>,
>> Dominique Barthel
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> De : Pascal Thubert <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> À :
>> "[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>"
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> Cc : lp-wan <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> Renvoyer - De : <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> Renvoyer - À : <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>,
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>,
>> Carles Montenegro <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>,
>> Dominique Barthel
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> publication. I find it very clear and highly readable; the examples and
>> FSM in appendix are really useful.
>>
>> that the sender goes to W=1-W; the thing is, how do we detect an error
>> so we can send an ack on error?
>>
>> that all fragments have been received. If they are missing FCN values
>> when the All-0 is received, we don't know.
>>
>> more guesswork can be done. If the missing FCN are not exactly a
>> contiguous sequence ending at 1, we know some fragments went
>> missing..
>>
>>       or ACK-Always mode Section 8
>> <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>,
>>       or ACK-Always mode Section 8
>> <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>,
>>    The UDP checksum operation is mandatory with IPv6 [RFC8200
>> <https://tools.ietf.org/html/rfc8200>] for most
>>
>>    The UDP checksum operation is mandatory with IPv6 [RFC8200
>> <https://tools.ietf.org/html/rfc8200>] for most
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Jul 2018 13:26:34 +0000

Right, only the last window with all ones may have valid trailer gaps now.

Regards,

Pascal

Le 17 juil. 2018 à 09:13, Nicolas Sornin <[email-masked]<mailto:[email-masked]>> a écrit :

From: lp-wan <[email-masked]<mailto:[email-masked]>> On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, July 17, 2018 2:55 PM
To: Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Cc: Shoichi Sakane <[email-masked]<mailto:[email-masked]>>; lp-wan <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16

WARNING - External Email

Regards,

Pascal

6 5 4 3 2 1 0
6 5 4 3 2 1 0

3 2 1 7

For instance;

6 4 2 0

Laurent

Thanks,
Shoichi

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal<http://www.semtech.com/legal>.

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 17 Jul 2018 14:27:09 +0000

I was also under the impression that this was the expected behaviour, and our experiments were based on that.

+1 for the clarification on the text.

Juan Carlos

From: lp-wan [mailto:[email-masked]] On Behalf Of Nicolas Sornin
Sent: July 17, 2018 9:12 AM
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>; Laurent Toutain <[email-masked]>
Cc: Shoichi Sakane <[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16

WARNING - External Email

Regards,

Pascal

6 5 4 3 2 1 0
6 5 4 3 2 1 0

3 2 1 7

For instance;

6 4 2 0

Laurent

Thanks,
Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 18 Jul 2018 00:05:30 +0900

Hi,

I don't disagree with the contiguous counter.  I have been understanding so too.

I am trying to understand what is your change exactly.

>>     If the FCN size is 3 then now the only possible sequence is

The FCN of All-0 windows are stared from 6.  It means MAX_WINDOW_FCN is 6.  But, the FCN of All-1 window is started from 3.

In page 35, draft-16:

   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.

My understanding from this text is that the FCN of All-1 window for rest four fragments are going to be 6 5 4 7.  Why your example in the All-1 window starts 3, not 6 ?  Will you change the first FCN in the All-1 window too ?

Regards,
Shoichi

On 7/17/18 22:26, Pascal Thubert (pthubert) wrote:
> Le 17 juil. 2018 à 09:13, Nicolas Sornin <[email-masked] <mailto:[email-masked]>> a écrit :
> 
>> *From:*lp-wan <[email-masked] <mailto:[email-masked]>> *On Behalf Of *Pascal Thubert (pthubert)
>> *Sent:* Tuesday, July 17, 2018 2:55 PM
>> *To:* Laurent Toutain <[email-masked] <mailto:[email-masked]>>
>> *Cc:* Shoichi Sakane <[email-masked] <mailto:[email-masked]>>; lp-wan <[email-masked] <mailto:[email-masked]>>
>> *Subject:* Re: [lp-wan] WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16
>>
>>  
>>
>> *WARNING - External Email*
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Le 17 juil. 2018 à 08:10, Laurent Toutain <[email-masked] <mailto:[email-masked]>> a écrit :
>>
>>     On Tue, Jul 17, 2018 at 3:05 AM Shoichi Sakane <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Hi Dominique,
>>
>>         On 7/17/18 10:51, [email-masked] <mailto:[email-masked]> wrote:
>>         > WG,
>>         >
>>         > De : Dominique Barthel <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > À : Pascal Thubert <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > Cc : lp-wan <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > Renvoyer - De : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > Renvoyer - À : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Carles Montenegro <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Dominique Barthel <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > De : Pascal Thubert <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > À : "[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > Cc : lp-wan <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > Renvoyer - De : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > Renvoyer - À : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Carles Montenegro <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Dominique Barthel <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>         > [email-masked] <mailto:[email-masked]>
>>         [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>> To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal <http://www.semtech.com/legal>.
> 
>

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 17 Jul 2018 11:24:01 -0400

HI Shoichi,

On Tue, Jul 17, 2018 at 11:06 AM Shoichi Sakane <[email-masked]> wrote:

> The FCN of All-0 windows are stared from 6.  It means MAX_WINDOW_FCN is
> 6.  But, the FCN of All-1 window is started from 3.
>
> In page 35, draft-16:
>
>    The rest
> My understanding from this text is that the FCN of All-1 window for rest
> four fragments are going to be 6 5 4 7.  Why your example in the All-1
> window starts 3, not 6 ?  Will you change the first FCN in the All-1 window
> too ?
>

You are right :-), this behavior simplifies the implementation having the
same behavior for All-0 and All-1 windows.

Laurent

> >> I was actually assuming what you are describing would be the rule, and
> at least this is how we are implementing it.
> >>
> >> *Cc:* Shoichi Sakane <[email-masked] <mailto:[email-masked]>>;
> lp-wan <[email-masked] <mailto:[email-masked]>>
> >> *Subject:* Re: [lp-wan] WGLC-2; shepherd review of
> >> There’s a corollary chance on the text that say to drop packets from
> the wrong window. It must be clear that, even with the new rule:
> >>
> >>
> >>
> >> Sending a ack, the receiver does not know what the right window is for
> the next packet. Depends whether the sender gets the ack or not. So the
> >> Le 17 juil. 2018 à 08:10, Laurent Toutain <
> [email-masked]>> a écrit :
> >>
> >>         Could you give an example when the FCN sequence is like a
> 4,3,2,0 ?  (I think that it's more likely 6 5 4 3 2 0 by the way)
> >>
> >>         Thanks,
> >>         Shoichi
> >>
> >>
> >>         > Following a discussion with Pascal and Laurent last week-end,
> I would like to bring the following to your attention.
> >>         >
> >>         > *What is it about?*
> >>         > More specifically, this is about fragmentation in Ack-Always
> or Ack-on-Error modes, where fragments are sent clustered together in
> windows, after which a SCHC ACK is expected by the fragment sender from the
> fragment receiver.
> >>         > The draft mandates that successive fragments are allocated
> contiguously decreasing FCN values and/but the last fragment in a window
> has an FCN of 0 (resp. 2^N-1) if the window is not the last one (resp. is
> the last one) of the SCHC packet.
> >>         >
> >>         > *Current situation*
> >>         > The intention was to leave it open for a window to carry a
> number of fragments less that MAX_WIND_FCN+1.
> >>         > This can be obtained by sending fragments in a contiguously
> decreasing sequence of FCN values finishing at a value different from 1,
> and jumping to 0 (resp. 2ˆN –1) for the last fragment.
> >>         > This results, in certain situations, in the receiver not
> being able to decide on its own if it has received all the fragments.
> >>         > This in turn results in extra delay and/or round-trip before
> being able to advance to the next window, in certain situations.
> >>         > We are proposing to change the specification to mandate that
> all windows but the last one have exactly MAX_WIND_FCN+1 fragments.
> >>         > As a consequence, the receiver, upon receiving an FCN==0
> fragment, immediately knows by itself if it has received all the fragments
> of that window.
> >>         > In turn, the algorithm becomes simpler to explain and some
> timeouts and/or round/trip can be avoided.
> >>         > Even better, if you already have an opinion on this, can you
> please voice it on the mailing list so that we get an early sense?
> >>         > "I don't see a use for partially filled fragmentation windows
> and I support the simplification brought about by mandating that all
> windows (but the last one) be full."
> >>         > Or
> >>         > "I have a case where being able to send incomplete windows is
> a strong benefit and I object to mandating that they be full."
> >>         >
> >>         > Thanks
> >>         >
> >>         > Dominique
> >>         >
> >>         > De : Dominique Barthel <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> >>         > À : Pascal Thubert <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>,
> "[email-masked] <mailto:
> [email-masked]> <mailto:
> [email-masked]>>" <
> [email-masked]> <mailto:
> [email-masked]>>>
> >>         > Cc : lp-wan <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >>         > Renvoyer - De : <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>
> >>         > Renvoyer - À : <[email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>, <[email-masked]
> <mailto:[email-masked]> <mailto:
> [email-masked]>>>, Carles Montenegro <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>, Dominique
> Barthel <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >>         > De : Pascal Thubert <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >>         > À : "[email-masked]
> <mailto:[email-masked]> <mailto:
> [email-masked]>>" <
> [email-masked]> <mailto:
> [email-masked]>>>
> >>         > Cc : lp-wan <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >>         > Renvoyer - De : <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>
> >>         > Renvoyer - À : <[email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>, <[email-masked]
> <mailto:[email-masked]> <mailto:
> [email-masked]>>>, Carles Montenegro <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>, Dominique
> Barthel <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >>         > Overall: I have reviewed this document and believe it is
> ready for publication. I find it very clear and highly readable; the
> examples and FSM in appendix are really useful.
> >>         >
> >>         > There are 3 tickets left to be closed, 15, 30 and 31 but I
> understand that they are fully addressed. They need to be closed.
> >>         >
> >>         >
> >>         >
> >>         > P 34 on abort:
> >>         >
> >>         > “
> >>         >
> >>         >
> >>         >
> >>         > How do we distinguish from an All-1 empty fragment? Maybe we
> can live without the All-1 Empty, just resend the full All-1 in case that
> is what was lost?
> >>         >
> >>         > [DB] the All-1 fragment, All-1 empty fragment and Send-Abort
> are distinguishable based on their length.
> >>         >   The All-1 fragment has MIC and payload, MIC is at least the
> size of an L2 Word. Paylaod is at least the size of an L2 Word.
> >>         >   So, all 3 are distinguishable, even in the presence of
> padding, which is always less than an L2 Word.
> >>         >
> >>         >
> >>         >
> >>         > In always ack mode:
> >>         >
> >>         > “
> >>         >
> >>         >                                              Since the sender
> is
> >>         >
> >>         > This indicates that the receiver does not know if it has
> received a full window and the sender indicates that it’s done. Yet later:
> >>         >
> >>         > “
> >>         >
> >>         > Expects the receiver to recognize a full window, and this is
> what triggers the ACK in a case of a retransmission. Also:
> >>         >
> >>         > “
> >>         >
> >>         >    Upon
> >>         >
> >>         > Indicates that there is no All-x at the end of a
> retransmission, so the receiver decides when to send an ack.
> >>         >
> >>         > The general idea is that the sender may not use all FCN
> values, and therefore it may be done sending the window without all the
> bits in the receiver bitmap being 1's.
> >>         > This is correctly captured in your third quote is a
> termination condition when there are repetition. If the receiver bitmap
> gets full of 1's, the receiver has no benefit of waiting any further and
> can send the SCHC ACK.
> >>         > As a consequence, the sender does not need to re-transmit the
> All-x fragment after repeating some intermediates fragments that were
> reported missing. This is captured in your fourth quote.
> >>         >
> >>         >
> >>         >
> >>         > We do not know that all fragments have been received; we just
> observe that the sender goes to W=1-W; the thing is, how do we detect an
> error so we can send an ack on error?
> >>         >
> >>         > [DB] if fragments will all FCN values were correctly
> received, we know that all fragments have been received. If they are
> missing FCN values when the All-0 is received, we don't know.
> >>         >
> >>         >   I'll leave it to the other authors to complement my
> response, but some more guesswork can be done. If the missing FCN are not
> exactly a contiguous sequence ending at 1, we know some fragments went
> missing..
> >>         >
> >>         >   I'd say an implementation could send a SCH ACK whenever
> there are missing FCN values (missing bits in the local bitmap). This is
> correct behaviour, even though it might be overly pessimistic.
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > Seems to me that the window MUST always start at 2N-2 and the
> last window (which may be the first) MAY end before FCN reaches zero.
> >>         >
> >>         >                                                      (Example
> for N=5,
> MAX_WIND_FCN MUST
> >>         > Though it is quite clear that this is true for both sender
> AND receiver abort, this is said only for the receiver…
> >>         >
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > “
> >>         >
> >>         > In other places, it is said that these MUST be defined in
> technology specific documents. This should be the same
> >>         >
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > 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,
> >>         > This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> >>         > 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,
> >>         > This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> >>         > 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.
> >>         >
> >>         >
> >>         >
> >> To view our privacy policy, including the types of personal information
> we collect, process and share, and the rights and options you have in this
> respect, see www.semtech.com/legal <http://www.semtech.com/legal>.
> >
> >

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 16:57:51 +0000

Actually, Laurent, the All-1 MUST start at FCN = MAX_WIND_FCN like the All-0 windows.
This has been mandated by the draft for at least a few revisions.
Your example should have been 6 5 4 7, not 3 2 1 7.

However, Soichi, the numbering starts at MAX_WIND_FCN, which does not have to be equal to 2ˆN-2.
I can explain why they can be different in another email.
So my example of 4 3 2 0 was also correct if MAX_WIND_FCN is 4 , it does not have to be 6 5 4 0.

Best regards

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 17 July 2018 11:24
À : Shoichi Sakane <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16

HI Shoichi,

On Tue, Jul 17, 2018 at 11:06 AM Shoichi Sakane <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

In page 35, draft-16:

   The rest

You are right :-), this behavior simplifies the implementation having the same behavior for All-0 and All-1 windows.

Laurent

Regards,
Shoichi

On 7/17/18 22:26, Pascal Thubert (pthubert) wrote:
> Le 17 juil. 2018 à 09:13, Nicolas Sornin <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> a écrit :
>
>> *From:*lp-wan <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> *On Behalf Of *Pascal Thubert (pthubert)
>> *To:* Laurent Toutain <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> *Cc:* Shoichi Sakane <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; lp-wan <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> Le 17 juil. 2018 à 08:10, Laurent Toutain <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> a écrit :
>>
>>     On Tue, Jul 17, 2018 at 3:05 AM Shoichi Sakane <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>         Hi Dominique,
>>
>>         On 7/17/18 10:51, dominique.barthel@orange..com<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> wrote:
>>         > WG,
>>         >
>>         > The intention was to leave it open for a window to carry a number of fragments less that MAX_WIND_FCN+1..
>>         > De : Dominique Barthel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > À : Pascal Thubert <pthubert@cisco..com<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>, "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>" <[email-masked]<mailto:draft-ietf-lpwan-ipv6-static-context-hc@ietf..org> <mailto:[email-masked]<mailto:draft-ietf-lpwan-ipv6-static-context-hc@ietf..org>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > Cc : lp-wan <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > Renvoyer - De : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > Renvoyer - À : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>, <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>, Carles Montenegro <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>, Dominique Barthel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > De : Pascal Thubert <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > À : "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > Cc : lp-wan <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > Renvoyer - De : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         > Renvoyer - À : <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>, <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>, Carles Montenegro <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>, Dominique Barthel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>>         >          be obtained.  Otherwise, the next Rule is tested..
>>         >
>>         > “
>>         >
>>         > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal<http://www.semtech.com/legal> <http://www.semtech.com/legal>.
>
>

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 18 Jul 2018 07:56:04 +0900

Now, I understand.

Thanks for your clarifications,

Shoichi

On 7/18/18 01:57, [email-masked] wrote:
> De : lp-wan <[email-masked] <mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked] <mailto:[email-masked]>>
> À : Shoichi Sakane <[email-masked] <mailto:[email-masked]>>
> On Tue, Jul 17, 2018 at 11:06 AM Shoichi Sakane <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     > Le 17 juil. 2018 à 09:13, Nicolas Sornin <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> a écrit :
>     > 
>     >> *From:*lp-wan <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> *On Behalf Of *Pascal Thubert (pthubert)
>     >> *To:* Laurent Toutain <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> *Cc:* Shoichi Sakane <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>; lp-wan <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> Le 17 juil. 2018 à 08:10, Laurent Toutain <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> a écrit :
>     >>
>     >>     On Tue, Jul 17, 2018 at 3:05 AM Shoichi Sakane <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     >>         Hi Dominique,
>     >>
>     >>         On 7/17/18 10:51, dominique.barthel@orange..com <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> wrote:
>     >>         > WG,
>     >>         >
>     >>         > Following a discussion with Pascal and Laurent last week-end, I would like to bring the following to your attention.
>     >>         >
>     >>         > *What is it about?*
>     >>         > This is about SCHC fragmentation.
>     >>         > More specifically, this is about fragmentation in Ack-Always or Ack-on-Error modes, where fragments are sent clustered together in windows, after which a SCHC ACK is expected by the fragment sender from the fragment receiver.
>     >>         > Within a window, the successive fragments are numbered with a Fragment Compressed Number (FCN).
>     >>         > The draft mandates that the first fragment in a window is numbered with FCN = MAX_WIND_FCN.
>     >>         > The draft mandates that successive fragments are allocated contiguously decreasing FCN values and/but the last fragment in a window has an FCN of 0 (resp. 2^N-1) if the window is not the last one (resp. is the last one) of the SCHC packet.
>     >>         >
>     >>         > *Current situation*
>     >>         > The intention was to leave it open for a window to carry a number of fragments less that MAX_WIND_FCN+1..
>     >>         > This can be obtained by sending fragments in a contiguously decreasing sequence of FCN values finishing at a value different from 1, and jumping to 0 (resp. 2ˆN –1) for the last fragment.
>     >>         > For example : a 4,3,2,0 sequence is meant to be legal.
>     >>         > This results, in certain situations, in the receiver not being able to decide on its own if it has received all the fragments.
>     >>         > This in turn results in extra delay and/or round-trip before being able to advance to the next window, in certain situations.
>     >>         > This also results in a hazier description of the algorithm, which impedes understanding.
>     >>         >
>     >>         > *Proposed change*
>     >>         > We are proposing to change the specification to mandate that all windows but the last one have exactly MAX_WIND_FCN+1 fragments.
>     >>         > They would be numbered from MAX_WIND_FCN downto 0 in a contiguous and complete sequence.
>     >>         > As a consequence, the receiver, upon receiving an FCN==0 fragment, immediately knows by itself if it has received all the fragments of that window.
>     >>         > In turn, the algorithm becomes simpler to explain and some timeouts and/or round/trip can be avoided.
>     >>         > However, some flexibility is sacrificed.
>     >>         >
>     >>         > *What should you do?*
>     >>         > We're going to discuss this point at the WG meeting on Thursday.
>     >>         > I wanted to give you a heads-up, so you can think about it ahead of time.
>     >>         > Even better, if you already have an opinion on this, can you please voice it on the mailing list so that we get an early sense?
>     >>         > This could take such form as
>     >>         > "I don't see a use for partially filled fragmentation windows and I support the simplification brought about by mandating that all windows (but the last one) be full."
>     >>         > Or
>     >>         > "I have a case where being able to send incomplete windows is a strong benefit and I object to mandating that they be full."
>     >>         >
>     >>         > Thanks
>     >>         >
>     >>         > Dominique
>     >>         >
>     >>         > De : Dominique Barthel <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Date : Wednesday 4 July 2018 01:44
>     >>         > À : Pascal Thubert <pthubert@cisco..com <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>, "[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>" <[email-masked] <mailto:draft-ietf-lpwan-ipv6-static-context-hc@ietf..org> <mailto:[email-masked] <mailto:draft-ietf-lpwan-ipv6-static-context-hc@ietf..org>> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Cc : lp-wan <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Objet : Re: WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16
>     >>         > Renvoyer - De : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Renvoyer - À : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>, <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>, Carles Montenegro <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>, Dominique Barthel <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Renvoyer - Date : Wednesday 4 July 2018 01:44
>     >>         >
>     >>         > Hello Pascal,
>     >>         >
>     >>         > Thanks for your thorough review and your comments.
>     >>         > See some responses inline
>     >>         > Best regards
>     >>         >
>     >>         > Dominique
>     >>         >
>     >>         > De : Pascal Thubert <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Date : Tuesday 3 July 2018 16:31
>     >>         > À : "[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>" <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Cc : lp-wan <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Objet : WGLC-2; shepherd review of draft-ietf-lpwan-ipv6-static-context-hc-16
>     >>         > Renvoyer - De : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Renvoyer - À : <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>, <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>, Carles Montenegro <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>, Dominique Barthel <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>         > Renvoyer - Date : Tuesday 3 July 2018 16:31
>     >>         >
>     >>         > Dear authors :
>     >>         >
>     >>         >  
>     >>         >
>     >>         > Many thanks for addressing all WGLC comments and posting before cut off.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > Please find below my shepherd review on draft 16:
>     >>         >
>     >>         >  
>     >>         >
>     >>         > Overall: I have reviewed this document and believe it is ready for publication. I find it very clear and highly readable; the examples and FSM in appendix are really useful.
>     >>         >
>     >>         > Many thanks to all the authors for the excellent work!
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > _Comments:_
>     >>         >
>     >>         >  
>     >>         >
>     >>         > There are 3 tickets left to be closed, 15, 30 and 31 but I understand that they are fully addressed. They need to be closed.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > P 34 on abort:
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >    Since an All-1 fragment MIC MUST be at least the size of an L2 Word,
>     >>         >
>     >>         >    a receiver can distinguish a Sender-Abort from an All-1 fragment,
>     >>         >
>     >>         >    even in the presence of padding.
>     >>         >
>     >>         > “
>     >>         >
>     >>         > How do we distinguish from an All-1 empty fragment? Maybe we can live without the All-1 Empty, just resend the full All-1 in case that is what was lost?
>     >>         >
>     >>         > [DB] the All-1 fragment, All-1 empty fragment and Send-Abort are distinguishable based on their length.
>     >>         >   The All-1 fragment has MIC and payload, MIC is at least the size of an L2 Word. Paylaod is at least the size of an L2 Word.
>     >>         >   The All-1 fragment has MIC and no payload.
>     >>         >   Sender-Abort has neither MIC nor payload.
>     >>         >   So, all 3 are distinguishable, even in the presence of padding, which is always less than an L2 Word.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > In always ack mode:
>     >>         >
>     >>         > “
>     >>         >
>     >>         >                                              Since the sender is
>     >>         >
>     >>         >    not obliged to always send a full window, some SCHC Fragment number
>     >>         >
>     >>         >    not set in the receiver memory may not correspond to losses.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > And
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    On the other hand, if the window value of the next received SCHC
>     >>         >
>     >>         >    Fragment is set to the next expected window value, this means that
>     >>         >
>     >>         >    the sender has received a correct encoded Bitmap reporting that all
>     >>         >
>     >>         >    SCHC Fragments have been received.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > This indicates that the receiver does not know if it has received a full window and the sender indicates that it’s done. Yet later:
>     >>         >
>     >>         > “
>     >>         >
>     >>         >           If all the bits of the Bitmap are set to one, the receiver
>     >>         >
>     >>         >    MUST send a SCHC ACK without waiting for an All-0 fragment and the
>     >>         >
>     >>         >    Inactivity Timer is initialized.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Expects the receiver to recognize a full window, and this is what triggers the ACK in a case of a retransmission. Also:
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    Upon
>     >>         >
>     >>         >    receipt of the SCHC ACK, if one or more SCHC Fragments have not yet
>     >>         >
>     >>         >    been received, the counter Attempts is increased and the sender
>     >>         >
>     >>         >    resends the missing SCHC Fragments again.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Indicates that there is no All-x at the end of a retransmission, so the receiver decides when to send an ack.
>     >>         >
>     >>         > This appears inconsistent.
>     >>         >
>     >>         > [DB] maybe we are not accurate enough in the text with the use of a "full" window.
>     >>         >
>     >>         > The general idea is that the sender may not use all FCN values, and therefore it may be done sending the window without all the bits in the receiver bitmap being 1's.
>     >>         > This is correctly captured in your third quote is a termination condition when there are repetition. If the receiver bitmap gets full of 1's, the receiver has no benefit of waiting any further and can send the SCHC ACK.
>     >>         > As a consequence, the sender does not need to re-transmit the All-x fragment after repeating some intermediates fragments that were reported missing. This is captured in your fourth quote.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > The same goes in Ack on error mode
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    When an All-0 fragment is received and all SCHC Fragments have been
>     >>         >
>     >>         >    received, the receiver updates the expected window value and expects
>     >>         >
>     >>         >    a new window and waits for the next SCHC Fragment.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > We do not know that all fragments have been received; we just observe that the sender goes to W=1-W; the thing is, how do we detect an error so we can send an ack on error?
>     >>         >
>     >>         > [DB] if fragments will all FCN values were correctly received, we know that all fragments have been received. If they are missing FCN values when the All-0 is received, we don't know.
>     >>         >
>     >>         >   I'll leave it to the other authors to complement my response, but some more guesswork can be done. If the missing FCN are not exactly a contiguous sequence ending at 1, we know some fragments went missing..
>     >>         >
>     >>         >   I'd say an implementation could send a SCH ACK whenever there are missing FCN values (missing bits in the local bitmap). This is correct behaviour, even though it might be overly pessimistic.
>     >>         >
>     >>         >
>     >>         >  
>     >>         >
>     >>         > Seems to me that the window MUST always start at 2N-2 and the last window (which may be the first) MAY end before FCN reaches zero.
>     >>         >
>     >>         > [DB] true, this is indeed what is specified. Except it's MAX_WIND_FCN, not necessarily 2^N-2.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > _Nits:_
>     >>         >
>     >>         > [DB] thanks. We'll take care of them 
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    o  Abort.  A SCHC Fragment format to signal the other end-point that
>     >>         >
>     >>         >       the on-going fragment transmission is stopped and finished.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >>        What is stopped in not one fragment but the whole fragmented packet
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    o  Abort.  A SCHC Fragment format to signal the other end-point that
>     >>         >
>     >>         >       the on-going transmission of a fragmented packet is interrupted and
>     >>         >
>     >>         >       will not continue.
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >    o  C: Checked bit.  Used in an acknowledgement (SCHC ACK) header to
>     >>         >
>     >>         >       determine if the MIC locally computed by the receiver matches (1)
>     >>         >
>     >>         >       the received MIC or not (0).
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Ø  The values  do not read naturally in the sentence
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    o  C: Checked bit.  Used in an acknowledgement (SCHC ACK) header. Set
>     >>         >
>     >>         >       (to 1) if the MIC locally computed by the receiver matches the MIC
>     >>         >
>     >>         >       received with the acknowledged All-1 fragment, and reset (to 0) if
>     >>         >
>     >>         >       it does not.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    o  Dev: Device.  A node connected to an LPWAN.  A Dev SHOULD
>     >>         >
>     >>         >       implement SCHC.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Ø  The SHOULD might not be appropriate, it is hard to specify that all LPWAN devices support SCHC.
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    o  Dev: SCHC Device.  A node that uses SCHC to transmit over an LPWAN.
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    o  W: Window bit.  A SCHC Fragment header field used in ACK-on-Error
>     >>         >
>     >>         >       or ACK-Always mode Section 8 <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>, which carries the same value for all
>     >>         >
>     >>         >       SCHC Fragments of a window.
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Ø  Need to indicate that it is flipped at each window
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    o  W: Window bit.  A SCHC Fragment header field used in ACK-on-Error
>     >>         >
>     >>         >       or ACK-Always mode Section 8 <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8>, which carries the same value for all
>     >>         >
>     >>         >       SCHC Fragments of a window, and is flipped between adjacent windows.
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >                                                           Both the Rule
>     >>         >
>     >>         >    ID and the Compression Residue potentially have a variable size, and
>     >>         >
>     >>         >    generally are not a mutiple of bytes in size.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Ø  Typo on multiple, may be reworded
>     >>         >
>     >>         > “
>     >>         >
>     >>         >                                                           Both the Rule
>     >>         >
>     >>         >    ID and the Compression Residue potentially have a variable size, and
>     >>         >
>     >>         >    are not necessarily aligned to an octet.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >          compressed header (with possibly a Compression Residue) SHOULD
>     >>         >
>     >>         >          be obtained.  Otherwise, the next Rule is tested..
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Ø  Not a proper use for uppercase SHOULD. What else could happen?
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >          compressed header (with possibly a Compression Residue) is
>     >>         >
>     >>         >          obtained.  Otherwise, the next Rule is tested.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >    Compression is done in order that Fields Descriptions appear in a
>     >>         >
>     >>         >    Rule.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Ø  This reads wrong. ‘In order that’ seems to say ’so that’
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >    Compression is done in the order that Fields Descriptions appear in a
>     >>         >
>     >>         >    Rule.
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         >               
>     >>         >
>     >>         > “
>     >>         >
>     >>         >                                                      (Example for N=5,
>     >>         >
>     >>         >       MAX_WIND_FCN MAY be set to 23, then subsequent FCNs are set
>     >>         >
>     >>         >       sequentially and in decreasing order, and the FCN will wrap from 0
>     >>         >
>     >>         >       back to 23).
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Not sure if the MAY is really useful. In any case, what’s important Is that 23 is the maximum
>     >>         >
>     >>         > “
>     >>         >
>     >>         >                                      (Example for N=5, MAX_WIND_FCN MUST
>     >>         >
>     >>         >       be lower or equal to 23, then subsequent FCNs are set
>     >>         >
>     >>         >       sequentially and in decreasing order, and the FCN will wrap from 0
>     >>         >
>     >>         >       back to MAX_WIND_FCN).
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >   transmitted, which MAY be especially beneficial in asymmetric
>     >>         >
>     >>         >       scenarios.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > MAY is not appropriate
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    transmitted, which is especially beneficial in asymmetric
>     >>         >
>     >>         >       scenarios.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    The Rule ID and Dtag values in the SCHC ACK messages MUST be
>     >>         >
>     >>         >    identical to the ones used in the SCHC Fragments that are being
>     >>         >
>     >>         >    acknowledged.  This allows matching the SCHC ACK and the
>     >>         >
>     >>         >    corresponding SCHC Fragments.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > ”
>     >>         >
>     >>         > The Window bit must match as well:
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “   The values of the Rule ID, the W bit, and the Dtag in the SCHC ACK messages MUST be
>     >>         >
>     >>         >    identical to the ones used in the SCHC Fragments that are being
>     >>         >
>     >>         >    acknowledged.  This allows matching the SCHC ACK and the
>     >>         >
>     >>         >    corresponding SCHC Fragments.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Should we clarify that in case of mismatch the transmission of the packet is aborted?
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    The Rule ID and Dtag values in the Receive-Abort message MUST be
>     >>         >
>     >>         >    identical to the ones used in the fragments of the SCHC Packet the
>     >>         >
>     >>         >    transmission of which is being aborted.
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Though it is quite clear that this is true for both sender AND receiver abort, this is said only for the receiver…
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    Then, the fragment receiver MAY determine the SCHC Fragment
>     >>         >
>     >>         >    reliability mode that is used for this SCHC Fragment based on the
>     >>         >
>     >>         >    Rule ID in that fragment
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > No need for MAY (there are others next that you might want to replace too)
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    Then, the fragment receiver determines the SCHC Fragment
>     >>         >
>     >>         >    reliability mode that is used for this SCHC Fragment based on the
>     >>         >
>     >>         >    Rule ID in that fragment
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > If the sender receives a SCK ACK
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > typo
>     >>         >
>     >>         > “
>     >>         >
>     >>         > If the sender receives a SCHC ACK
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > Again, occurrences of “ MAY “ that are now warranted in 8.6.  Supporting multiple window sizes
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    The default initial value for the Inactivity timer, as well as the
>     >>         >
>     >>         >    maximum number of retries for a specific SCHC ACK, denoted
>     >>         >
>     >>         >    MAX_ACK_RETRIES, are not defined in this document, and need to be
>     >>         >
>     >>         >    defined in other documents (e.g. technology-specific profiles).
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         > In other places, it is said that these MUST be defined in technology specific documents. This should be the same
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > Fig 27 does not indicate padding for the ack, though it could be needed there too
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > 10.6.  Hop Limit field
>     >>         >
>     >>         >  
>     >>         >
>     >>         > For DL, MO could be ignore and CDA could be not-sent; DL=1 would be assumed on receive.
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    The UDP checksum operation is mandatory with IPv6 [RFC8200 <https://tools.ietf.org/html/rfc8200>] for most
>     >>         >
>     >>         >    packets but recognizes that there are exceptions to that default
>     >>         >
>     >>         >    behavior.
>     >>         >
>     >>         > “
>     >>         >
>     >>         > Missing something in the sentence
>     >>         >
>     >>         > “
>     >>         >
>     >>         >    The UDP checksum operation is mandatory with IPv6 [RFC8200 <https://tools.ietf.org/html/rfc8200>] for most
>     >>         >
>     >>         >    packets but the specification recognizes that there are exceptions
>     >>         >
>     >>         >    to that default behavior.
>     >>         >
>     >>         > “
>     >>         >
>     >>         >  
>     >>         >
>     >>         >  
>     >>         >
>     >>         > Cheers,
>     >>         >
>     >>         >  
>     >>         >
>     >>         > 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.
>     >>         >
>     >>         >
>     >>         >
>     >>         > _______________________________________________
>     >>         > lp-wan mailing list
>     >>         > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >>         > https://www.ietf.org/mailman/listinfo/lp-wan
>     >>         >
>     >>
>     >>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >> To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal <http://www.semtech.com/legal> <http://www.semtech.com/legal>.
>     > 
>     >