Subject: [lp-wan] Ticket #9: Reordering between RGW and NGW (closed)

From: Ana Minaburo <[email-masked]>
Date: Tue, 3 Apr 2018 11:41:50 +0200

Description  <https://trac.ietf.org/trac/lpwan/ticket/9#comment:description>

The Radio Gateway and the Network Gateway are connected to the Internet,
Therefore data unit reordering might happen there. How about deleting the
constraint text:

"LPWAN networks typically follow a star topology, and therefore data unit
reordering is not expected in such networks".

During the Interim meeting on January 16th, a discussion gets started
around leaving the text as it is. The current text is consistent.
Reordering may create many weird cases. Don't try to be better than you
need because there is an associated cost. We don't support out of order
fragments.

Perhaps some technologies do not do reordering but at the SCHC level
packets arrive in order.
comment:1 <https://trac.ietf.org/trac/lpwan/ticket/9#comment:1>Changed 5
weeks ago
<https://trac.ietf.org/trac/lpwan/timeline?from=2018-02-26T13%3A13%3A36-08%3A00&precision=second>
 by ana@…

Interim Jan 16th
------------------------------

   - non-reordering: Laurent states that the protocol can now deal with
   re-ordering. We originally had this statement about LPWAN networks not
   re-ordering packets but we can remove it.

Carles: Also in no ack mode.
Laurent: even if a few fragments arrive out of order, no problem.
Pascal: Keep the text as it is. The current text is consistent. Reordering
may create many weird cases. Don't try to be better than you need because
there is an associated cost. We don't support out of order fragments.
Dominique: Out of-order can happen between multiple gateways and the NS.
The point is valid to know if current SCHC works in presence of re-ordering
or not. We can limit reordering to a limited time.
Pascal: connection times between gateways and NS are nothing.
Dominique: some early gateways use 3G for backhaul. Can have up to one
second of delay. So out-of-ordering could take place between a 3G gateway
and a wired gateway.
Julien: The LoRaWAN system is made to keep the frame order. The NS will put
frames in order before delivering to the upper layer.
Dominique: pretty sure I saw out of order packets in a LoRaWAN system but,
thinking about it, it might have been on the wireless logger interface,
maybe not on the data interface.
Dominique: will check anyway with Orange experts whether OoO can happen on
the data interface.
Edgar: Got a bit confused from the previous discussion since assumed that
LORA has the combining of the packet in the network gateway that connects
multiple base stations, and according to the SCHC architecture drawing the
SCHC functions are located after the network gateway, not between the
network gateway and the base stations. Just wondering if then this wasn't
intended like that.

comment:2 <https://trac.ietf.org/trac/lpwan/ticket/9#comment:2>Changed 5
weeks ago
<https://trac.ietf.org/trac/lpwan/timeline?from=2018-02-26T13%3A14%3A18-08%3A00&precision=second>
 by ana@…

Interim Jan 30th
---
Laurent: protocol is flexible enough to support reordering between RGW and
NGW. Dominique was to check the situation with LoRaWAN.

Edgar: comment that re-ordering should not happen between RGW and NGW is
not needed. Works anyway.
JCZ: most of my comments on clarification of the architecture definition.
Suggest keeping the text assuming a star topology, just to avoid opening a
can of worms.
Ana: packet duplpication as already discussed when reviewing the state
machine. The state machine drops duplicate packets.
Edgar: this was the fragmetnation state machines. How about compression
state machines?
Edgar: commetn was mainly about possiblity that tje decomporessor would
receive twice the same packet, amybe even once fragmented adn once not
fargmented.
Laurent: not our problem. Compressor will still work
Edgar: looking at making this future proof if we go beyond star topology.
Laurent: forwarding capability works. But we don't want routing protocol,
etc.
Laurent: we can start with this, and if we see a need/problem we'll write
another document.
Carles: re-ordering prblem in ACL-always, last windows compreises several
fragmetns, 6,5, 4, 7. If 7 arrives frist at receiver, does the mechanism
still work ? In ACK-always, bleive yes, albeit less eficiently.
Laurent: the last window now behaves the same in ACK-always and
ACK-on-error.
<<< sorry I was interrupted, missed a minute or so of the meeting. Please
help filling in the blank >>>>
Pascal: thought we hasd a corner case in the last window. Are you sure it
works?
JCZ: referring to the reason why we put the MIC?
Pascal: no, MIC is much older. Discussion at the last interim. Don't
remember.
Edgar:
Laurent: "out of sequence" instead of "re-ordering".
Carles: "assume that out of sequence will not happen".
Pascal: even if rare, if it happens, we accept it. Did not do my review
with this assumptation. If we say re-ordering is possible, need to redo the
review with this assumption in mind.
Edgar:
Laurent: could we keep a "no re-ordering assumed"in the SCHC document, and
in the technology dcument "after frther examination, a reordering of so
much is acceptable".

comment:3 <https://trac.ietf.org/trac/lpwan/ticket/9#comment:3>Changed 5
weeks ago
<https://trac.ietf.org/trac/lpwan/timeline?from=2018-02-26T13%3A16%3A04-08%3A00&precision=second>
 by ana@…

   - *Resolution* set to *fixed*
   - *Status* changed from *new* to *closed*

Ana: We add out of sequence instead of re-ordering.
------------------------------
comment:4 <https://trac.ietf.org/trac/lpwan/ticket/9#comment:4>Changed 1
second ago
<https://trac.ietf.org/trac/lpwan/timeline?from=2018-04-03T02%3A39%3A33-07%3A00&precision=second>
 by ana@…

This ticket has been closed, we have added in the Introduction the
following text:

In response to this need, this document also defines a
fragmentation/reassembly mechanism, which supports the IPv6 MTU requirement
over LPWAN technologies. Such functionality has been designed under the
assumption that data unit out-of-sequence delivery will not happen between
the entity performing fragmentation and the entity performing reassembly.