Subject: [lp-wan] Proposal: MIC optional, especially for non-UDP traffic

From: Juan Carlos Zuniga <[email-masked]>
Date: Thu, 19 Jul 2018 16:05:43 +0000

(I’m separating the three topics so that we can follow different discussion threads.)

Hello Sothy,

Thanks for the feedback. It is good to know that you also see some value for this option for NB-IoT.

Best,

Juan Carlos

From: sivasothy shanmugalingam [mailto:[email-masked]]
Sent: July 19, 2018 10:21 AM
To: Juan Carlos Zuniga <[email-masked]>
Cc: [email-masked]; lp-wan <[email-masked]>; [email-masked]
Subject: Re: [lp-wan] WGLC in effect, ending soon! Re: Second last call for SCHC/IP

On Thu, Jul 19, 2018 at 4:59 AM, Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

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

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

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

  1.  The SCHC mechanism could be used for transporting non-UDP/IP packets. In this case, if the integrity of the whole fragmented packet can be guaranteed by L2 means, the use of the MIC in the All-1 fragment could sometimes be avoided. If so, the use of the MIC should be made optional, provided there are sufficient L2 means to guarantee the integrity of all the fragments of a packet.

Hello all, and Zuniga,

I agree this point and In NB IOT, data delivery can be use of reliable or not reliable. If use reliable delivery, MIC and some mechanism in SCHC Fragment is overhead. Therefore, I wish to have  fragment over reliable delivery network or fragment over not reliable delivery network.

Best regards
Sothy

---

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

Hello all,

As a quick note before the upcoming brainstorming session, I want to re-iterate that the MIC is not just there for data integrity.
Its second purpose is to make sure all the fragments have reached the receiver, which has no other way of knowing, in the current algorithm.
For example, if the last fragment before the All-1 fragment goes missing, there's nothing else that the receiver will notice, than the MIC mismatch.
Removing the MIC would mean adding a confirmation from the sender to the receiver that the bitmap advertised in the SCHC ACK matched the one in the transmitter.
Best regards

Dominique

De : Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Date : Thursday 19 July 2018 12:05
À : sivasothy shanmugalingam <[email-masked]<mailto:[email-masked]>>
Cc : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, lp-wan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Proposal: MIC optional, especially for non-UDP traffic

Hello Sothy,

Best,

Juan Carlos

From: sivasothy shanmugalingam [mailto:[email-masked]]
Sent: July 19, 2018 10:21 AM
To: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; lp-wan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lp-wan] WGLC in effect, ending soon! Re: Second last call for SCHC/IP

Hello all, and Zuniga,

Best regards
Sothy

_________________________________________________________________________________________________________________________

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

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

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Fri, 20 Jul 2018 14:37:16 +0000

Hello Dominique,

There could be a case where the underlaying L2 technology could provide information about missing frames (e.g. frame counter). This could be used to infer that a fragment has gone missing. That’s what I was trying to say by integrity of all fragments.

Since this is tech-dependant, the proposal is to relax the baseline text and make the use of MIC optional, provided there are L2 means to guarantee both data integrity and reception of all fragments.

Best,

Juan Carlos

From: [email-masked] [mailto:[email-masked]]
Sent: July 20, 2018 10:24 AM
To: Juan Carlos Zuniga <[email-masked]>; sivasothy shanmugalingam <[email-masked]>
Cc: lp-wan <[email-masked]>; [email-masked]
Subject: Re: Proposal: MIC optional, especially for non-UDP traffic

Hello all,

Dominique

Hello Sothy,

Best,

Juan Carlos

Hello all, and Zuniga,

Best regards
Sothy

Thank you.

---

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

Thanks for expliciting this. Your proposed mechanism to make sure all fragments have reached the receiver entail adding an interface to the re-assembler to convey that information.
I guess this needs to be described somewhere.

Dominique

De : Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Date : Friday 20 July 2018 10:37
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, sivasothy shanmugalingam <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : RE: Proposal: MIC optional, especially for non-UDP traffic

Hello Dominique,

Best,

Juan Carlos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: July 20, 2018 10:24 AM
To: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>; sivasothy shanmugalingam <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Proposal: MIC optional, especially for non-UDP traffic

Hello all,

Dominique

Hello Sothy,

Best,

Juan Carlos

Hello all, and Zuniga,

Best regards
Sothy

Thank you.

---

From: sivasothy shanmugalingam <[email-masked]>
Date: Fri, 20 Jul 2018 16:58:39 +0200

will it make sense? Let's see the example here.

Input: DataToBeSent

Condition: Underlay transport (L2 or overlay) has no guarantee for reliable
delivery, in-sequence delivery, and integrity
               Byte aligned

if UnderlayTransportMTU < DataToBeSent
    Apply fragmentation as in IETF draft

Condition: Underlay transport (L2 or overlay) has no guarantee for reliable
delivery, in-sequence delivery, and integrity
                bit aligned

if UnderlayTransportMTU < DataToBeSent
     Apply fragmentation relaxing with padding.

Continue your proposal

Best regards
Sothy

On Fri, Jul 20, 2018 at 4:41 PM, <[email-masked]> wrote:

> Thanks for expliciting this. Your proposed mechanism to make sure all
> fragments have reached the receiver entail adding an interface to the
> re-assembler to convey that information.
> De : Juan Carlos Zuniga <[email-masked]>
> À : Dominique Barthel <[email-masked]>, sivasothy
> shanmugalingam <[email-masked]>
> Cc : lp-wan <[email-masked]>, "draft-ietf-lpwan-ipv6-static-
> [email-masked]" <[email-masked]>
> There could be a case where the underlaying L2 technology could provide
> information about missing frames (e.g. frame counter). This could be used
> to infer that a fragment has gone missing. That’s what I was trying to say
> by integrity of all fragments.
>
>
>
> Since this is tech-dependant, the proposal is to relax the baseline text
> and make the use of MIC optional, provided there are L2 means to guarantee
> both data integrity and reception of all fragments.
>
>
>
> Best,
>
>
>
> Juan Carlos
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* July 20, 2018 10:24 AM
> *To:* Juan Carlos Zuniga <[email-masked]>; sivasothy
> shanmugalingam <[email-masked]>
> *Cc:* lp-wan <[email-masked]>; draft-ietf-lpwan-ipv6-static-
> [email-masked]
> *Subject:* Re: Proposal: MIC optional, especially for non-UDP traffic
>
>
>
> Hello all,
>
>
>
> As a quick note before the upcoming brainstorming session, I want to
> re-iterate that the MIC is not just there for data integrity.
>
> Its second purpose is to make sure all the fragments have reached the
> receiver, which has no other way of knowing, in the current algorithm.
>
> For example, if the last fragment before the All-1 fragment goes missing,
> there's nothing else that the receiver will notice, than the MIC mismatch.
>
> Removing the MIC would mean adding a confirmation from the sender to the
> receiver that the bitmap advertised in the SCHC ACK matched the one in the
> transmitter.
>
> Best regards
>
>
>
> Dominique
>
>
>
> *De : *Juan Carlos Zuniga <[email-masked]>
> *Date : *Thursday 19 July 2018 12:05
> *À : *sivasothy shanmugalingam <[email-masked]>
> *Cc : *Dominique Barthel <[email-masked]>, lp-wan <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Objet : *Proposal: MIC optional, especially for non-UDP traffic
>
>
>
> *From:* sivasothy shanmugalingam [mailto:[email-masked] <[email-masked]>]
> *Sent:* July 19, 2018 10:21 AM
> *To:* Juan Carlos Zuniga <[email-masked]>
> *Cc:* [email-masked]; lp-wan <[email-masked]>;
> [email-masked]
> *Subject:* Re: [lp-wan] WGLC in effect, ending soon! Re: Second last call
> for SCHC/IP
>
>
>
>
>
>
>
> On Thu, Jul 19, 2018 at 4:59 AM, Juan Carlos Zuniga <
> [email-masked]> wrote:
>
> Hello all,
>
>
>
> I took a look at the draft on the Fragmentation section and I’m happy to
> see that it is getting in a much better shape!
>
>
>
> However, I believe that there are still some clarifications and nits that
> need to be corrected before submitting it for publication.
>
>
>
>    1. The SCHC mechanism could be used for transporting non-UDP/IP
>    packets. In this case, if the integrity of the whole fragmented packet can
>    be guaranteed by L2 means, the use of the MIC in the All-1 fragment could
>    sometimes be avoided. If so, the use of the MIC should be made optional,
>    provided there are sufficient L2 means to guarantee the integrity of all
>    the fragments of a packet.
>
>
>
> Hello all, and Zuniga,
>
>
>
> I agree this point and In NB IOT, data delivery can be use of reliable or
> not reliable. If use reliable delivery, MIC and some mechanism in SCHC
> Fragment is overhead. Therefore, I wish to have  fragment over reliable
> delivery network or fragment over not reliable delivery network.
>
>
>
> Best regards
>
> Sothy
>
>
>