Subject: [lp-wan] some topics to discuss related to schc-lorawan draft

From: Arunprabhu Kandasamy <[email-masked]>
Date: Tue, 17 Dec 2019 11:44:41 +0100

Hi,

I would like to bring a few discussion, that was going around with the
lorawan authors, to the ML;

Topic 1:
The current version of the lorawan draft mandates that the last fragment
i.e. All-1 MUST-NOT carry any tile in it.
We could, however, have some flexibility here, meaning the last fragment
"MAY" carry the last tile in it whenever possible.
The advantage we have here is;
  - we could avoid sending one additional fragment when the last tile is
smaller than regular tile size. for example 4 bytes.

Since we have configurations in lorawan draft that would result in
byte-aligned headers that will not induce padding, having
"penultimate tile MUST be a regular size" wouldn't be a problem as well.

Having configurations that could lead to padding (non-byte-aligned headers)
would enforce borrowing penultimate tile when the last tile is smaller than
l2word. But this case is out of the scope for this document.

Topic 2(new):
 Since we don't have a dtag in the headers, it might create some ambiguity
in the receiver to manage statemachines for the devices when it receives a
new fragmented packet while the inactivity timer is still active. Note that
the sender doesn't have the knowledge of the inactivity timer.
It would be nice to have a section in the draft to discuss this behavior
and probably a solution to overcome it.

what are your thoughts?

Thanks,
Arun

---

From: Ivaylo Petrov <[email-masked]>
Date: Tue, 17 Dec 2019 16:44:00 +0100

Hello Arun,

Thank you for your email! Could you elaborate on the sentense "Note that
the sender doesn't have the knowledge of the inactivity timer".

Thanks,
Ivaylo

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s).

It is strictly forbidden to share any part of this message with any third
party, without the written consent of the sender.

If you have received this message by mistake, please notify the sender
immediately by email and delete the message and any file attached to it.
Thank you!

On Tue, Dec 17, 2019 at 11:45 AM Arunprabhu Kandasamy <[email-masked]> wrote:

> Having configurations that could lead to padding (non-byte-aligned
> headers) would enforce borrowing penultimate tile when the last tile is
> smaller than l2word. But this case is out of the scope for this document.
>
>
> Topic 2(new):
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Arunprabhu Kandasamy <[email-masked]>
Date: Wed, 18 Dec 2019 09:25:57 +0100

Hi Ivo,
In order to avoid overlapping the state machine of the receiver, the sender
could wait some time, if he has knowledge of the inactivity timer
configured at receiver, (inactivity timer + delta) before sending the
fragments from next session. But I think, this is not the behavior that is
specified in the draft.
So, it would be good to have some section or sentence that gives the
implementors some suggestions on how to interleave fragments when there is
no dtag.

thanks

On Tue, Dec 17, 2019 at 4:44 PM Ivaylo Petrov <[email-masked]> wrote:

> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s).
>
>>  Since we don't have a dtag in the headers, it might create some
>> ambiguity in the receiver to manage statemachines for the devices when it
>> receives a new fragmented packet while the inactivity timer is still
>> active. Note that the sender doesn't have the knowledge of the inactivity
>> timer.

-- 

Arun

---

From: <[email-masked]>
Date: Wed, 18 Dec 2019 09:52:06 +0000

Hello all,

Indeed, the generic SCHC specification does not require the sender to have an inactivity timer.
But it does not preclude it.
It could be a good implementation recommendation, to be part of a schc-over-foo draft, especially if Dtag is not used in the profile.
Best regards

Dominique

De : Arunprabhu Kandasamy <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 18 December 2019 09:25
À : Ivaylo Petrov <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>, Dominique Barthel <[email-masked]<mailto:[email-masked]>>, Olivier Gimenez <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] some topics to discuss related to schc-lorawan draft

Hi Ivo,
In order to avoid overlapping the state machine of the receiver, the sender could wait some time, if he has knowledge of the inactivity timer configured at receiver, (inactivity timer + delta) before sending the fragments from next session. But I think, this is not the behavior that is specified in the draft.
So, it would be good to have some section or sentence that gives the implementors some suggestions on how to interleave fragments when there is no dtag.

thanks

On Tue, Dec 17, 2019 at 4:44 PM Ivaylo Petrov <[email-masked]<mailto:[email-masked]>> wrote:
Hello Arun,

Thank you for your email! Could you elaborate on the sentense "Note that the sender doesn't have the knowledge of the inactivity timer".

Thanks,
Ivaylo

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s).

It is strictly forbidden to share any part of this message with any third party, without the written consent of the sender.

If you have received this message by mistake, please notify the sender immediately by email and delete the message and any file attached to it. Thank you!

On Tue, Dec 17, 2019 at 11:45 AM Arunprabhu Kandasamy <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I would like to bring a few discussion, that was going around with the lorawan authors, to the ML;

Topic 1:
The current version of the lorawan draft mandates that the last fragment i.e. All-1 MUST-NOT carry any tile in it.
We could, however, have some flexibility here, meaning the last fragment "MAY" carry the last tile in it whenever possible.
The advantage we have here is;
  - we could avoid sending one additional fragment when the last tile is smaller than regular tile size. for example 4 bytes.

Since we have configurations in lorawan draft that would result in byte-aligned headers that will not induce padding, having
"penultimate tile MUST be a regular size" wouldn't be a problem as well.

Having configurations that could lead to padding (non-byte-aligned headers) would enforce borrowing penultimate tile when the last tile is smaller than l2word. But this case is out of the scope for this document.

Topic 2(new):
 Since we don't have a dtag in the headers, it might create some ambiguity in the receiver to manage statemachines for the devices when it receives a new fragmented packet while the inactivity timer is still active. Note that the sender doesn't have the knowledge of the inactivity timer.
It would be nice to have a section in the draft to discuss this behavior and probably a solution to overcome it.

what are your thoughts?

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

--

Arun

_________________________________________________________________________________________________________________________

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: Olivier Gimenez <[email-masked]>
Date: Thu, 19 Dec 2019 12:35:19 +0000

From: [email-masked] <[email-masked]>

[OG] If Arun case is real and there is an ambiguity when DTAG is not used, is it better to have the mitigation in SCHC specification instead of SCHC-over-foo ?

Hi Ivo,

[OG] By doing it you create an additional latency for the second SCHC packet you might want to avoid.
Also if first few SCHC messages are lost the timer in the receiver will start after sender side, and you will not solve your issue.

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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Dec 2019 13:32:48 +0000

It is really late to change SCHC since the IESG reviews are well advanced. But a sentence has only a local impact, which id the case here, then I believe it is probably still doable.
In the vein of “when DTAG is not used, the technology Profile SHOULD indicate the inactivity timer on the receiver and the sender SHOULD refrain from starting another fragmented packet during that time to avoid a confusion wiht overlapping fragmented messages “

All the best

Pascal

From: lp-wan <[email-masked]> On Behalf Of Olivier Gimenez
Sent: jeudi 19 décembre 2019 13:35
To: [email-masked]; Arunprabhu Kandasamy <[email-masked]>
Cc: lp-wan <[email-masked]>; Ivaylo Petrov <[email-masked]>
Subject: Re: [lp-wan] some topics to discuss related to schc-lorawan draft

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hi Ivo,

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>.