Subject: [lp-wan] Large-time data delivery with SCHC

From: Edgar Ramos <[email-masked]>
Date: Tue, 18 Jan 2022 15:19:39 +0000

Hi all,
I wanted to bring up the discussion about the delay tolerant (or large time transmissions) of data using SCHC.
During the December meeting I gave a presentation providing the problem statement and a possible solution using SCHC fragmentation and reliability mechanisms (Delay tolerant over SCHC <https://datatracker.ietf.org/meeting/interim-2021-lpwan-13/materials/slides-interim-2021-lpwan-13-sessa-delay-tolerent-over-schc-00> (slides-interim-2021-lpwan-13-sessa-delay-tolerant-over-schc)<https://datatracker.ietf.org/doc/slides-interim-2021-lpwan-13-sessa-delay-tolerent-over-schc/>). The main idea is to treat an transmittable object as a big IP packet and enable possibilities for very long time outs and multiple profiles configured for SCHC usage for both the downloads and uploads of large objects.

One of the issues was the comment that the current charter does not include a mandate to work on this area explicitly. So the first question is if we need to update the charter to work on the topic.
Secondly, the solution was mainly targeting a problem observed in the Cellular IoT but it was commented in the session that there could be similar needs for a solution targeting other LPWAN technologies and in that case a draft covering a general solution seems to be desirable. Is this really the case ? .

How should we proceed ?, is it the charter discussion needed first ? or should we start with a draft ?

Cheers

Edgar R.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Jan 2022 08:00:47 +0000

Hello Edgar

We can have a draft any time. It's adoption that will lead to procedural hassle.
If people in the ML are interested in the discussion, maybe we'll progress the personal submission enough to figure what we want in terms of charter.
So please publish if you have anything. (hopefully in line with Eric's words at the meeting) I discourage the use of "DTN" as a term in that draft. You may call it jumbo or something.
Note also that you may want to split the large content in COAP blocks to keep each block of a reasonable size if the comm is lost, and enable a packetization without IP fragmentation when decompressing.
An interesting aspect for this group would be the capability to resume a dtag at a certain window after a desync. And possibly the capability to hold a dtag as well,  meaning that the usual timers are suspended for a longer time.

Keep safe;

Pascal

From: lp-wan <[email-masked]> On Behalf Of Edgar Ramos
Sent: mardi 18 janvier 2022 16:20
To: lp-wan <[email-masked]>
Subject: [lp-wan] Large-time data delivery with SCHC

Hi all,

Cheers

Edgar R.

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 25 Jan 2022 11:36:51 +0100

Hello Edgar,

Acklio is interesting in this area, and would like to participate with you
in the study and implementation of this problem.

Ana

On Tue, Jan 18, 2022 at 4:19 PM Edgar Ramos <edgar.ramos=
[email-masked]> wrote:

> During the December meeting I gave a presentation providing the problem
> statement and a possible solution using SCHC fragmentation and reliability
> mechanisms (Delay tolerant over SCHC
> <https://datatracker.ietf.org/meeting/interim-2021-lpwan-13/materials/slides-interim-2021-lpwan-13-sessa-delay-tolerent-over-schc-00>
> (slides-interim-2021-lpwan-13-sessa-delay-tolerant-over-schc)
> <https://datatracker.ietf.org/doc/slides-interim-2021-lpwan-13-sessa-delay-tolerent-over-schc/>).
> The main idea is to treat an transmittable object as a big IP packet and
> enable possibilities for very long time outs and multiple profiles
> configured for SCHC usage for both the downloads and uploads of large
> objects.
>
>
>
> One of the issues was the comment that the current charter does not
> include a mandate to work on this area explicitly. So the first question is
> if we need to update the charter to work on the topic.
>
> Secondly, the solution was mainly targeting a problem observed in the
> Cellular IoT but it was commented in the session that there could be
> similar needs for a solution targeting other LPWAN technologies and in that
> case a draft covering a general solution seems to be desirable. Is this
> really the case ? .
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>