Re: [lp-wan] Flow validation in ACK-on-error Mode

[Rodrigo Muñoz <[e-mail]>]

Hi Juan Carlos. My comments below:

In your flow, you are showing a “Retransmission Timer” time between the
retransmitted Reg Frag 1 and the All-1.


*[Rodrigo]:* Yes. This timer is definided
in draft-petrov-lpwan-ipv6-schc-over-lorawan document. In the 5.5.1 said:
"If this ACK is not received the end-device sends an all-0 (or an all-1)
fragment with no payload to request an SCHC ACK retransmission. The
periodicity between retransmission of the all-0/all-1 fragments is
device/application specific and may be different for each device (not
specified).



*[JCZ] **Ok, I thought you were referring your question to the authors of
the baseline LPWAN SCHC specification
(draft-ietf-lpwan-ipv6-static-context-hc), which allows several
implementations for different radio technologies. The answer I gave you was
with different implementation in mind (e.g. Sigfox), in which you don’t
have to wait for a retransmission timer to continue transmitting your other
fragments after retransmitting the missing one. If draft-petrov defines it
differently I would let the authors of that draft comment (BTW, the draft
has been replaced by draft-ietf-lpwan-schc-over-lorawan).*



*[Rodrigo]: I’ll write to the authors of the LoRaWAN draft. In LoRaWAN you
can send fragments while you wait for the ACK the lost fragment, but in my
scheme, I supposed that the ACK is sent by the receiver the end of the SCHC
window of the lost fragment.*






If the All-1 is the fragment that would have normally followed Reg Frag 4,
there is no need for the sender to wait between retransmitting Reg Frag 4
and the All-1.


* [Rodrigo]*: I don't understand this. Could you explain it in more detail
please? Remember that in my diagram, fragment 1 is lost, but fragments 2, 3
and 4 correctly reach the receiver. In addition, I assume that these
fragments are not in the last window, therefore an All-1 SCHC message
should not be sent


*[JCZ] **Do you mean that there are other fragments after 4 that are not
depicted, or that the All-1 is transmitted alone in the last window?
Perhaps explaining this would help the discussion.*



*[Rodrigo]: In my scheme, I supposed that the ACK is sent by the receiver
the end of the SCHC window of the lost fragment. The size window is of 4
fragments. I send the All-1 because in the draft
(draft-ietf-lpwan-ipv6-static-context-hc-21) say in 8.4.3.1
<http://8.4.3.1>: “On Retransmission Timer expiration: if Attempts is
strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send either
the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to
the last window,”*





This All-1 would trigger again the receiver to send a SCHC ACK, which would
notify the sender of the correct (or not) reception of all the previous
fragments.
* [Rodrigo]:* Yes, I also agree with you

The problem is: what happens when the sender relays the Frag 1 message and
this message is lost. Neither the sender nor the receiver have timers to
start retransmissions again, or do they have them?



I corrected the diagram to give more clarity



*[JCZ] **Again, in the implementation that I have in mind the transmitter
would send the missing fragment followed by the next not-yet-transmitted
fragments in the same window. I would let Ivo et al. comment about the
implementation they propose in their draft.*



*[Rodrigo]: I’ll write to the authors of the LoRaWAN draft. Thanks*


*Olivier and Ivailo. Can you help me?*

El lun., 16 sept. 2019 a las 20:13, Juan Carlos Zuniga (<
[e-mail]>) escribió:

> Hi Rodrigo,
>
>
>
> *From:* Rodrigo Muñoz <[e-mail]>
> *Sent:* September 16, 2019 3:59 PM
> *To:* Juan Carlos Zuniga <[e-mail]>
> *Cc:* [e-mail]; Sandra Cespedes <[e-mail]>
> *Subject:* Re: [lp-wan] Flow validation in ACK-on-error Mode
>
>
>
> Thanks Juan Carlos for your response.
>
> My comments below:
>
> In your flow, you are showing a “Retransmission Timer” time between the
> retransmitted Reg Frag 1 and the All-1.
> [Rodrigo]: Yes. This timer is definided
> in draft-petrov-lpwan-ipv6-schc-over-lorawan document. In the 5.5.1 said:
> "If this ACK is not received the end-device sends an all-0 (or an all-1)
> fragment with no payload to request an SCHC ACK retransmission. The
> periodicity between retransmission of the all-0/all-1 fragments is
> device/application specific and may be different for each device (not
> specified).
>
>
>
> *[JCZ] **Ok, I thought you were referring your question to the authors of
> the baseline LPWAN SCHC specification
> (draft-ietf-lpwan-ipv6-static-context-hc), which allows several
> implementations for different radio technologies. The answer I gave you was
> with different implementation in mind (e.g. Sigfox), in which you don’t
> have to wait for a retransmission timer to continue transmitting your other
> fragments after retransmitting the missing one. If draft-petrov defines it
> differently I would let the authors of that draft comment (BTW, the draft
> has been replaced by draft-ietf-lpwan-schc-over-lorawan).*
>
>
>
> If the All-1 is the fragment that would have normally followed Reg Frag 4,
> there is no need for the sender to wait between retransmitting Reg Frag 4
> and the All-1.
> [Rodrigo]: I don't understand this. Could you explain it in more detail
> please? Remember that in my diagram, fragment 1 is lost, but fragments 2, 3
> and 4 correctly reach the receiver. In addition, I assume that these
> fragments are not in the last window, therefore an All-1 SCHC message
> should not be sent
>
>
> *[JCZ] **Do you mean that there are other fragments after 4 that are not
> depicted, or that the All-1 is transmitted alone in the last window?
> Perhaps explaining this would help the discussion.*
>
>
> This All-1 would trigger again the receiver to send a SCHC ACK, which
> would notify the sender of the correct (or not) reception of all the
> previous fragments.
> [rodrigo]: Yes, I also agree with you
>
> The problem is: what happens when the sender relays the Frag 1 message and
> this message is lost. Neither the sender nor the receiver have timers to
> start retransmissions again, or do they have them?
>
>
>
> I corrected the diagram to give more clarity
>
>
>
> *[JCZ] **Again, in the implementation that I have in mind the transmitter
> would send the missing fragment followed by the next not-yet-transmitted
> fragments in the same window. I would let Ivo et al. comment about the
> implementation they propose in their draft.*
>
>
>
> *Best, Juan Carlos *
>
>
>
>
>
> El lun., 16 sept. 2019 a las 13:06, Juan Carlos Zuniga (<
> [e-mail]>) escribió:
>
> Hello Rodrigo,
>
>
>
> Thanks for your enquiry.
>
>
>
> In your flow, you are showing a “Retransmission Timer” time between the
> retransmitted Reg Frag 1 and the All-1.
>
>
>
> If the All-1 is the fragment that would have normally followed Reg Frag 4,
> there is no need for the sender to wait between retransmitting Reg Frag 4
> and the All-1.
>
>
>
> This All-1 would trigger again the receiver to send a SCHC ACK, which
> would notify the sender of the correct (or not) reception of all the
> previous fragments.
>
>
>
> I hope this helps.
>
>
>
> Best,
>
>
>
> Juan Carlos
>
>
>
> *From:* lp-wan <[e-mail]> *On Behalf Of *Rodrigo Muñoz
> *Sent:* September 16, 2019 10:42 AM
> *To:* [e-mail]
> *Cc:* Sandra Cespedes <[e-mail]>
> *Subject:* [lp-wan] Flow validation in ACK-on-error Mode
>
>
>
> Dear Author,
>
>
>
> I am working on the implementation of the SCHC standard for Sigfox and
> LoRaWAN. I have the following doubt regarding the data flow when there is a
> failure in the transmission of a SCHC fragment in the ACK-on-error Mode.
>
>
> In this email, I attach my draft compression. Is this flow ok?
>
>
> I have assumed the following:
>
>    - The SCHC Ack is sent immediately by the receiver at the end of the
>    window.
>
> Regards
>
> --
>
> -------------------------------------------
> *Rodrigo Muñoz Lara*
>
>
>
>
> --
>
> -------------------------------------------
> *Rodrigo Muñoz Lara*
>


-- 
-------------------------------------------
*Rodrigo Muñoz Lara*