Subject: [lp-wan] Increasing window size

From: Laurent Toutain <[email-masked]>
Date: Fri, 7 Sep 2018 09:06:15 +0200

Hi,

I think we have a very good meeting last Wednesday and we are very close to
a global solution for fragmentation.

As I said during the meeting, the w bit should be extended to a window
field of variable size (as FCN). This will help to avoid confusion when ack
a window. Current Ack on err suffers of this, since we have only 2 windows
(0 and 1) the solution fails is 2 donwlink ack are lost.

Lets take W size of 3 bits and FCN of 3 bits.

  W = 0 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |---------X.  |

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |------------>|

  FCN=0 |------------>|

        |   X---------| 0/1101111

        |             |

        |             |

   W = 1 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |------------>|

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |------------>|

  FCN=0 |------------>|

        |   X---------| 0/1101111

        |             |

   W = 2 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |------------>|

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |----------X  |

  FCN=0 |------------>|

        |<------------| 0/1101111

  0/4   |------------>|

        |<------------| 2/1111101

We have the Ack on error behavior. If a window is full then no ack is send.
In the scenario, the first window is acked since one frag is missing. The
ack is lost, after a timeout since the sender receives nothing he continues
with the next window. The window is well received but since the receiver
dodn’t get the missing frag on w=0 it continues to ack it. The ack is lost,
then sender continues with w=2. At the end it still ack w=0, it receives
the missing frag. The w=1 is full then it acks the w=2 with the missing
frag. If w=2 was totally received, the w=2 will not have been acked.

The protocol works even if we loose all the ack, since we still mandate to
ack explicitly the All-1 window.

The impact on the header size is not that big. If we take one of the worst
case, for instance 8 Byte of payload for frag and a 1500 Byte packet with
FCN size of 3.

We need 188 frag. So 27 windows; So 5 bits for w and 3 bytes for FCN, i.e.
a Byte. This may be a good solution for Edgar’s jumbogram.

Another good property is that it limits the size of the bitmap. We can so
in the future imagine a hierarchical bitmap, as proposed by Carles, if MTU
changes.

I didn't do a deep analyze of all the strange cases, but I wanted to have
your opinion before going further.

Laurent

---

From: ana minaburo <[email-masked]>
Date: Fri, 7 Sep 2018 10:15:09 +0200

Hello,

I agree that this could be a good idea but I have some questions.

Does the variable size for w will be generalized for all the modes, I
prefer to leave Ack-always with w=1?

In which window the MIC will be sent, in the last one All-1 as in
ACK-always?

If the ACKs are lost all the way, are they retransmitted in order? After
each window, does the receiver try to send in order the loosen ACKs?

For example, if I follow the logic of your example:

  W = 0 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |---------X.  |

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |------------>|

  FCN=0 |------------>|

        |   X---------| 0/1101111

        |             |

        |             |

   W = 1 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |------------>|

  FCN=3 |-------X---->|

  FCN=2 |------------>|

  FCN=1 |------------>|

  FCN=0 |------------>|

        |   X---------| 0/1101111

        |   X---------| 1/1110111

        |             |

   W = 2 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |------------>|

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |----------X  |

  FCN=0 |------------>|

  0/4   |------------>|

        |<------------| 1/1110111

  1/3   |------------>|

In your example, an ACK is sent after each window, in this example, it is
the ACK of w=0 that is lost each time, does this is better than ACK-always?
What I mean, when an error arrives in ACK-on-error mode  I send an ACK and
if I understand well your example I keep sending the ACK after each window
the difference with ACK-always is not clear. What happens if I sent the ACK
in the corresponding window when needed and then if it is lost I resend it
only after the last window?

For example, if I follow the logic of your example:

  W = 0 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |---------X.  |

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |------------>|

  FCN=0 |------------>|

        |   X---------| 0/1101111

        |             |

        |             |

   W = 1 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |------------>|

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |------------>|

  FCN=0 |------------>|

          |             |

          |             |

   W = 2 |             |

  FCN=6 |------------>|

  FCN=5 |------------>|

  FCN=4 |------------>|

  FCN=3 |------------>|

  FCN=2 |------------>|

  FCN=1 |----------X  |

  FCN=0 |------------>|

  0/4   |------------>|

Can the downlink send multiple frames one after the other once?

Only some quick thoughts after reading your mail

Regards
Ana

On Fri, Sep 7, 2018 at 9:06 AM, Laurent Toutain <laurent.toutain@imt-
atlantique.fr> wrote:

> Hi,
>
>
>
> I think we have a very good meeting last Wednesday and we are very close
> to a global solution for fragmentation.
>
>
>
> We have the Ack on error behavior. If a window is full then no ack is
> send. In the scenario, the first window is acked since one frag is missing.
> The ack is lost, after a timeout since the sender receives nothing he
> continues with the next window. The window is well received but since the
> receiver dodn’t get the missing frag on w=0 it continues to ack it. The ack
> is lost, then sender continues with w=2. At the end it still ack w=0, it
> receives the missing frag. The w=1 is full then it acks the w=2 with the
> missing frag. If w=2 was totally received, the w=2 will not have been acked.
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 7 Sep 2018 16:11:48 +0200

Hi Laurent, all,

I agree that, in ACK-on-Error, there is no need to constrain the W field
(i.e. the window index) to a single bit. (In ACK-Always, a single-bit W
field works well already.)

I view your proposal in the lines of the approach we have generally
followed of a generic SCHC mechanism, which then can be tuned/optimized
for specific underlying LPWAN technologies. As per your proposal, if a
specific technology wants to use ACK-on-Error and a 1-bit W field,
mandating so is still possible in the corresponding SCHC-over-foo
document.

Of course, there is a trade-off, as pointed out in the discussion with
Dominique: reducing the size of the W field increases the probability of
ambiguity at the receiver. Again, maybe the decision on this can be made
in the corresponding SCHC-over-foo document.

I also see that your proposal assumes use of the "Resend SCHC ACK" message
in Juan Carlos' slide 6 (@IETF 102), which IMHO is good because it
replaces the simplistic approach in the current version of the SCHC draft
(i.e. -16) of sending a Receiver-Abort when a fragment that does not
belong to the current window is received. (The rest of Juan Carlos'
proposal, basically the sender behavior, can also be considered regardless
of the size of the W field.)

Thanks,

Carles

> send.