Subject: [lp-wan] Interleaving packets between fragments

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Apr 2017 13:14:13 +0000

Dear authors :

Considering the time it may take to send a large fragmented packet, do we want to have provisions for interleaving a higher priority packet?

If not:
-  we may have to abort a transmission when emergency occurs, that's bad but simple to do.
- As a result, a long frame in a busy environment may take a lot of energy and never go through. There c/should be rules to abandon it, maybe make that implementation dependent?

If yes:
- then we have to consider the consequences on running timers, which may need to be restarted, but not for ever, upon an interleaved packet.
- can we interleave a fragmented frame? If so we need to define an optional datagram-tag, probably together with the rule ID and the CFN. A datagram tag of 1 bit can be used as a flip flop to disambiguate some situations where fragments of the next frame are confused with fragments of a previous frame. More bits would make it a frame identifier and could allow interleaving of a few fragmented frames.

What do you think?

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Apr 2017 15:43:00 +0200

Ha, shades of RFC2686.

In a route-over situation, it is hard to imagine how to avoid interleaving (a router may simply not have all fragments of packet 1 when it gets packet 2 — should it leave the link idle? How long before it gives up?).

In a star situation, where the sender is identical with the fragmenter, this is easier to avoid.  However, if latency is an issue, some mechanism such as that in RFC2686 is needed (which simply used a 2-bit or 4-bit class number to be able to stack transmission suspensions — reordering does not happen in PPP).

Grüße, Carsten

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 4 Apr 2017 19:08:21 +0200

Dear authors, 

I second the question that Pascal has raised. I see how it is not trivial and I’d like to encourage you to keep in mind the LPWAN characteristics when addressing the question. Some questions to consider:
- Can we realistically expect to have multiple parallel fragmented data flows of the same type flowing through the same compressor, where the compressor would be likely to decide to change in runtime the order? 
- How do we abort a data flow that went bad? For example, the compressor got restarted for some reason, and the end-device is waiting for some fragment.. with valid MIC. Which would never arrive (as the compressor doesn’t have the packets already sent to sent the appropriate MIC).

I think there is a case for an « abort » mechanism.

<chair hat off>
This would be highly device-dependent, as you may have non-constrained devices capable of handling multiple parallel transmissions, but in most cases you’d be expected to have a single transmission. For example, would it be possible to add an « abort » flag to the fragmentation header for the last fragment? Then again, we’ll need to add it to the ACK. Timers could be expensive to keep (not saying that we should not expect them.. just that if we can do without them that would be perfect), especially if we make them mandatory for the fragmentation. 
<chair hat on>

So, to sum up - if we can KISS it, I’m all for it. 

Thanks, Pascal, for catching that!

Best,
Alexander

> Le 4 avr. 2017 à 15:14, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Dear authors :
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan