Subject: Re: [lp-wan] Increasing window index size

From: <[email-masked]>
Date: Fri, 7 Sep 2018 09:02:28 +0000

[Changing the subject line to be more accurate]

Hello Laurent,

I read and understood your proposal.
I have one question, though. You say:
> The protocol works even if we loose all the ack, since …
Do you mean it?
What about the following situation (with W now on 2 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 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 3 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |<------------| 0/1101111
  0/4   |------------>|

What fragment will be re-transmitted ? Do you manage the ambiguity between the first W=0 window and the second W=0 window? Or is this just a rare case that leads to an error (the MIC will be wrong)?
Thanks

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Date : Friday 7 September 2018 09:06
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Increasing window size

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Laurent Toutain <[email-masked]>
Date: Fri, 7 Sep 2018 14:37:17 +0200

Hi Dominique,

I think that we may impose for this mode that the window number never rolls
down. You must have enough numbers for your entire packet.
The math I gave in an example are encouraging and Ethernet frame need only
1 byte to number the windows and the FCN. With longer fragment this can
also be the case of Edgar's jumbograms.

If you don't have enough windows you can use Ack Always. I'm not sure it
necessary to merge both behaviors. For example when you have finish one
window round you must collect all the Ack before going to the next round.

Laurent

Laurent

On Fri, Sep 7, 2018 at 11:02 AM <[email-masked]> wrote:

> What fragment will be re-transmitted ? Do you manage the ambiguity between
> the first W=0 window and the second W=0 window? Or is this just a rare case
> that leads to an error (the MIC will be wrong)?
> Thanks
>
> Dominique
>
>
> De : lp-wan <[email-masked]> on behalf of Laurent Toutain <
> [email-masked]>
> À : lp-wan <[email-masked]>
> 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.
>
>
>
> 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 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.
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Sep 2018 14:12:23 +0000

Hello all

It seems that a window count that never wraps and a single window are pretty much the same thing from the transmission standpoint.

 Just that this enables intermediate check points that may be missed, in which case confusion arises, thus Juan Carlos’s proposal etc... iow the alternate check points are more are than good in terms of algorithms.

The problem with the single window is the size of the bitmap.

The best of both worlds could be to send a single window but reply errors with bitmap snippets, a snippet being the same as the nth smaller window. So if my window is indexed in 10 bits and my ack bitmap can only be 6 bits, I can signal the snippet offset using 4 bits and then the bitmap. The result is the same as ack on error but all the recovery happens in the end, so we avoid the checkpoint problem.

Would that simplify the logic?

Regards,

Pascal

Le 7 sept. 2018 à 14:38, Laurent Toutain <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Dominique,

I think that we may impose for this mode that the window number never rolls down. You must have enough numbers for your entire packet.
The math I gave in an example are encouraging and Ethernet frame need only 1 byte to number the windows and the FCN. With longer fragment this can also be the case of Edgar's jumbograms.

If you don't have enough windows you can use Ack Always. I'm not sure it necessary to merge both behaviors. For example when you have finish one window round you must collect all the Ack before going to the next round.

Laurent

Laurent

On Fri, Sep 7, 2018 at 11:02 AM <[email-masked]<mailto:[email-masked]>> wrote:
[Changing the subject line to be more accurate]

Hello Laurent,

Do you mean it?

  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 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 3 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|

Dominique

Hi,

  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 |------------>|

Laurent

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Sun, 9 Sep 2018 11:17:04 +0000

Hello all,

The way I understand Laurent’s proposal is a similar behaviour as the ACK-on-Error State Machine that I presented at the last interim call, with the advantage that W is no longer constrained to be binary (i.e. one bit) and it can therefore roll back several windows.

I also agree with the response to Dominique, in that this behaviour would be better handled if W is not allowed to roll down. This was in fact one of the complications of the presented State Machine, which would be probably be simplified with this new proposal.

It is true that a window count that never wraps and a single window are similar from the transmitter point of view. The main advantage is from the receiver perspective, which saves in ACK transmissions and bitmap size.

On the other hand, protocol-wise the cost to pay would be in the number of W bits. This impact would need to be assessed for each underlaying technology.

Finally, to answer Pascal’s proposal, seems to me that even though the logic would probably be simplified, the cost of loosing the last ACK would need to be carefully assessed.

Best,

Juan Carlos

________________________________
From: lp-wan <[email-masked]> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]>
Sent: September 7, 2018 10:12 AM
To: Laurent Toutain
Cc: lp-wan; BARTHEL Dominique IMT/OLPS
Subject: Re: [lp-wan] Increasing window index size

Hello all

Regards,

Pascal

Hi Dominique,

Laurent

Laurent

Hello Laurent,

Do you mean it?

  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 |------------>|

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

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

        |             |

    W = 3 |             |

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

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

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

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

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

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

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

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

        |             |

    W = 0 |             |

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

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

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

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

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

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

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

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

Dominique

Hi,

  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/4   |------------>|

Laurent

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Sep 2018 06:23:58 +0000

Hello Juan Carlos :

I understand that the all 1s is still acknowledged even in ack-on-error. With my proposal, that a ack is the beginning of all retries, so we never miss the beginning and have to negotiate rollbacking in the middle of the transmission, IOW, my proposal just pushes all the retrying to the end so as not to mix the initial sending and the resendings. It seemed to make things easier, but maybe not since we still have to listen for aborts. I'm not pushing for it, just showing a slight variation to weight complexity.

All the best,

Pascal

From: Juan Carlos Zuniga <[email-masked]>
Sent: dimanche 9 septembre 2018 13:17
To: Pascal Thubert (pthubert) <[email-masked]>; Laurent Toutain <[email-masked]>
Cc: lp-wan <[email-masked]>; BARTHEL Dominique IMT/OLPS <[email-masked]>
Subject: Re: [lp-wan] Increasing window index size

Hello all,

The way I understand Laurent's proposal is a similar behaviour as the ACK-on-Error State Machine that I presented at the last interim call, with the advantage that W is no longer constrained to be binary (i.e. one bit) and it can therefore roll back several windows.

On the other hand, protocol-wise the cost to pay would be in the number of W bits. This impact would need to be assessed for each underlaying technology..

Finally, to answer Pascal's proposal, seems to me that even though the logic would probably be simplified, the cost of loosing the last ACK would need to be carefully assessed.

Best,

Juan Carlos

From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>

Hello all

 Just that this enables intermediate check points that may be missed, in which case confusion arises, thus Juan Carlos's proposal etc... iow the alternate check points are more are than good in terms of algorithms..

Regards,

Pascal

Laurent

Laurent

Hello Laurent,

I read and understood your proposal.
I have one question, though. You say:
> The protocol works even if we loose all the ack, since ...
Do you mean it?

  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 |------------>|

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

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

        |             |

    W = 3 |             |

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

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

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

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

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

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

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

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

        |             |

    W = 0 |             |

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

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

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

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

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

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

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

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

Dominique

Hi,

  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/4   |------------>|

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.

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.

Laurent

Thank you.

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 10 Sep 2018 09:30:24 +0000

Hello Pascal,

Thanks for the further clarification. Understood. I also meant that the proposal simplifies the SW implementation but the fact that it concentrates control messaging at one point in time may have negative implications on the overall performance due to radio conditions (e.g. burst errors at that time).

Best,

Juan Carlos

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: September 10, 2018 7:24 AM
To: Juan Carlos Zuniga <[email-masked]>; Laurent Toutain <[email-masked]>
Cc: lp-wan <[email-masked]>; BARTHEL Dominique IMT/OLPS <[email-masked]>
Subject: RE: [lp-wan] Increasing window index size

Hello Juan Carlos :

All the best,

Pascal

From: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Sent: dimanche 9 septembre 2018 13:17
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>; BARTHEL Dominique IMT/OLPS <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] Increasing window index size

Hello all,

Best,

Juan Carlos

Hello all

Regards,

Pascal

Laurent

Laurent

Hello Laurent,

Do you mean it?

  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 |------------>|

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

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

        |             |

    W = 3 |             |

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

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

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

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

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

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

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

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

        |             |

    W = 0 |             |

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

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

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

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

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

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

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

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

Dominique

Hi,

  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/4   |------------>|

Laurent

Thank you.

---

From: Laurent Toutain <[email-masked]>
Date: Mon, 10 Sep 2018 11:39:03 +0200

Hi

A bigger window allows to desynchronize the retransmisson from the initial
transmission. I like Pascal proposal, but it is more a implementation
issue, than a global optimization. Let's imagine a slotted network where
you have 10 time more uplink than downlink, downlink slots may be used to
transmit bitmap when problems are detected. On some other situation it
could be better to send it at then end. I will suggest to be perminive on
that in the the protocol description.

Laurent

On Mon, Sep 10, 2018 at 11:30 AM Juan Carlos Zuniga <
[email-masked]> wrote:

> Hello Pascal,
>
>
>
> Thanks for the further clarification. Understood. I also meant that the
> proposal simplifies the SW implementation but the fact that it concentrates
> control messaging at one point in time may have negative implications on
> the overall performance due to radio conditions (e.g. burst errors at that
> time).
>
>
>
> Best,
>
>
>
> Juan Carlos
>
>
>
>
>
>
>
> *From:* Pascal Thubert (pthubert) <[email-masked]>
> *Sent:* September 10, 2018 7:24 AM
> *To:* Juan Carlos Zuniga <[email-masked]>; Laurent Toutain <
> *Cc:* lp-wan <[email-masked]>; BARTHEL Dominique IMT/OLPS <
> [email-masked]>
> *Subject:* RE: [lp-wan] Increasing window index size
>
>
>
> Hello Juan Carlos :
>
>
>
> I understand that the all 1s is still acknowledged even in ack-on-error.
> With my proposal, that a ack is the beginning of all retries, so we never
> miss the beginning and have to negotiate rollbacking in the middle of the
> transmission, IOW, my proposal just pushes all the retrying to the end so
> as not to mix the initial sending and the resendings. It seemed to make
> things easier, but maybe not since we still have to listen for aborts. I’m
> not pushing for it, just showing a slight variation to weight complexity.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
>
>
> *From:* Juan Carlos Zuniga <[email-masked]>
> *Sent:* dimanche 9 septembre 2018 13:17
> *To:* Pascal Thubert (pthubert) <[email-masked]>; Laurent Toutain <
> *Cc:* lp-wan <[email-masked]>; BARTHEL Dominique IMT/OLPS <
> [email-masked]>
> *Subject:* Re: [lp-wan] Increasing window index size
>
>
>
> Hello all,
>
>
>
> The way I understand Laurent’s proposal is a similar behaviour as the
> ACK-on-Error State Machine that I presented at the last interim call, with
> the advantage that W is no longer constrained to be binary (i.e. one bit)
> and it can therefore roll back several windows.
>
>
>
> I also agree with the response to Dominique, in that this behaviour would
> be better handled if W is not allowed to roll down. This was in fact one of
> the complications of the presented State Machine, which would be probably
> be simplified with this new proposal.
>
>
>
> It is true that a window count that never wraps and a single window are
> similar from the transmitter point of view. The main advantage is from the
> receiver perspective, which saves in ACK transmissions and bitmap size.
>
>
>
> On the other hand, protocol-wise the cost to pay would be in the number of
> W bits. This impact would need to be assessed for each underlaying
> technology..
>
>
>
> Finally, to answer Pascal’s proposal, seems to me that even though the
> logic would probably be simplified, the cost of loosing the last ACK would
> need to be carefully assessed.
>
>
>
> Best,
>
>
>
> Juan Carlos
> ------------------------------
>
> *From:* lp-wan <[email-masked]> on behalf of Pascal Thubert
> (pthubert) <pthubert=[email-masked]>
> *Sent:* September 7, 2018 10:12 AM
> *To:* Laurent Toutain
> *Cc:* lp-wan; BARTHEL Dominique IMT/OLPS
> *Subject:* Re: [lp-wan] Increasing window index size
>
>
>
> Hello all
>
>
>
> It seems that a window count that never wraps and a single window are
> pretty much the same thing from the transmission standpoint.
>
>
>
>  Just that this enables intermediate check points that may be missed, in
> which case confusion arises, thus Juan Carlos’s proposal etc... iow the
> alternate check points are more are than good in terms of algorithms..
>
>
>
> The best of both worlds could be to send a single window but reply errors
> with bitmap snippets, a snippet being the same as the nth smaller window.
> So if my window is indexed in 10 bits and my ack bitmap can only be 6 bits,
> I can signal the snippet offset using 4 bits and then the bitmap. The
> result is the same as ack on error but all the recovery happens in the end,
> so we avoid the checkpoint problem.
>
>
>
> Le 7 sept. 2018 à 14:38, Laurent Toutain <
> [email-masked]> a écrit :
>
> Hi Dominique,
>
>
>
> I think that we may impose for this mode that the window number never
> rolls down. You must have enough numbers for your entire packet.
>
> *De : *lp-wan <[email-masked]> on behalf of Laurent Toutain <
> *Date : *Friday 7 September 2018 09:06
> *À : *lp-wan <[email-masked]>
> *Objet : *[lp-wan] Increasing window size
>
>
>
> Hi,
>
>
>
> [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Sep 2018 14:18:56 +0000

Hello Laurent

Still we need to know when the sender expects to receive something. For instance an abort. Is that expected after each fragment? Each window?

Take care,

Pascal

From: Laurent Toutain <[email-masked]>
Sent: lundi 10 septembre 2018 11:39
To: Juan Carlos Zuniga <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; lp-wan <[email-masked]>; BARTHEL Dominique IMT/OLPS <[email-masked]>
Subject: Re: [lp-wan] Increasing window index size

Hi

A bigger window allows to desynchronize the retransmisson from the initial transmission. I like Pascal proposal, but it is more a implementation issue, than a global optimization. Let's imagine a slotted network where you have 10 time more uplink than downlink, downlink slots may be used to transmit bitmap when problems are detected. On some other situation it could be better to send it at then end. I will suggest to be perminive on that in the the protocol description.

Laurent

On Mon, Sep 10, 2018 at 11:30 AM Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>> wrote:
Hello Pascal,

Best,

Juan Carlos

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: September 10, 2018 7:24 AM
To: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>; Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>; BARTHEL Dominique IMT/OLPS <[email-masked]<mailto:[email-masked]>>
Subject: RE: [lp-wan] Increasing window index size

Hello Juan Carlos :

I understand that the all 1s is still acknowledged even in ack-on-error. With my proposal, that a ack is the beginning of all retries, so we never miss the beginning and have to negotiate rollbacking in the middle of the transmission, IOW, my proposal just pushes all the retrying to the end so as not to mix the initial sending and the resendings. It seemed to make things easier, but maybe not since we still have to listen for aborts. I’m not pushing for it, just showing a slight variation to weight complexity.

All the best,

Pascal

Hello all,

Best,

Juan Carlos

Hello all

 Just that this enables intermediate check points that may be missed, in which case confusion arises, thus Juan Carlos’s proposal etc... iow the alternate check points are more are than good in terms of algorithms..

Regards,

Pascal

Laurent

Laurent

Hello Laurent,

Do you mean it?

  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 |------------>|

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

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

        |             |

    W = 3 |             |

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

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

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

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

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

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

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

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

        |             |

    W = 0 |             |

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

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

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

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

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

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

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

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

Dominique

Hi,

  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/4   |------------>|

Laurent

Thank you.