Subject: [lp-wan] ACK size exceeding the L2 MTU

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 17 May 2017 10:28:09 +0200

Hi again,

Even if a fragment receiver may support both the "bitmap" and "list" ACK
types, there may be scenarios where none of these ACK types can fit a
single L2 MTU. (Another approach might avoid this problem, but it follows
a different scheme for error correction and it is not considered here, see
my next email.)

The above problem will only happen under the following three conditions:

 i) the IPv6 packet is very large (in the sense of an LPWAN context),
 ii) a relatively high number of fragment losses per packet occurs, and
 iii) the L2 MTU has a size in the order of ~10 bytes.

The three conditions being met simultaneously might be a relatively rare
event, but still might happen. How should we handle this?

A simple solution is to define a "multi-PDU" ACK, which can be carried
over more than one L2 PDU. In practice, a maximum of two/three PDUs would
be needed to carry the ACK for a 1280-byte IPv6 packet in the worst case.

Assuming R = 8 bits:

- In LoRaWAN, a bitmap ACK fits the L2 MTU, except for DR0 in the US
(where two L2 PDUs will be needed to carry the bitmap for a 1280-byte IPv6
packet).

- In SIGFOX, three L2 PDUs will be needed to carry the bitmap for a
1280-byte IPv6 packet.

A bit from the Rule ID could signal whether a PDU is the last one carrying
a multi-PDU ACK.

Comments?

Thanks,

Carles

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 17 May 2017 17:56:18 +0200

Hello,

In the case where  the ACK size exceeds the L2 MTU,  you use window mode

To go forward with your thoughts, which will be more expensive retrying a very corrupted packet or drop it and send it again? 
What could be a relatively high number of fragment losses? 20%, 30% ? 

Ana

> On 17 May 2017, at 10:28, Carles Gomez Montenegro <[email-masked]> wrote:
> 
> Hi again,
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 18 May 2017 09:27:04 +0200

Hi Ana,

> In the case where  the ACK size exceeds the L2 MTU,  you use window mode

That is an option. However, while ACK size would potentially be shorter
than in Packet mode (with multi-PDU ACK), the number of ACK data units in
Window mode would be equal to or greater than the one with Packet mode
(with multi-PDU ACK).

For example, assume an IPv6 packet needs 100 fragments to be carried, and
10 of those fragments are lost. If the LPWAN technology has an 8-byte MTU
in the "feedback channel" (i.e. from the fragment receiver to the fragment
sender), a 2-PDU ACK will be needed in Packet mode (with either bitmap or
list type ACK).

However, in Window mode:

- N=6 (window size: 63 frags), then 2 windows are used, 2 ACKs needed.
- N=5 (window size: 31 frags), then 4 windows are used, 4 ACKs needed.
- ...

(The ACKs that would be needed after retries if losses can be recovered
are not included in the count, but should also be considered.)

If the ACKs are being sent in the expensive direction, one might want to
reduce the number of data units required to carry ACKs.

However, there may be other considerations for the Window or Packet mode
choice (section 8.3 of the SCHC document), and the original question was
about handling the situation in Packet mode (if possible).

> To go forward with your thoughts, which will be more expensive retrying a
> very corrupted packet or drop it and send it again?

I think this is a very good and also difficult question.

One might think that it is better to try to amortize the fragments that
did arrive in a quite bad fragmented IPv6 packet transmission.

On the other hand, a link may be suffering a "bad quality interval", but
conditions might vary after a while and the channel quality may become
good afterwards. So persisting when a channel is bad could be more
expensive than resending after a while in this case.

A sender could decide to abort an on-going transmission, and if some upper
layer determines that the packet needs to be resent, there would be a
retransmission later.

> What could be a relatively high number of fragment losses? 20%, 30% ?

Yes, something in that order, assuming that the IPv6 packet we are
considering here is large (e.g. ~100 fragments).

To be clearer, a "relatively high number of fragment losses" would be a
number of losses that would lead to a "list" ACK to exceed the L2 MTU.

Cheers,

Carles