Subject: [lp-wan] retransmission in the last window

From: Arun <[email-masked]>
Date: Wed, 16 Aug 2017 10:49:49 +0200

Hi Carles and all, 

Scenario : More than one fragment is lost in the last window of ACK always mode; 
Per my understanding, this is bit different than the retransmission behavior that is observed in non-last window.
Since there can be lesser number of fragments than the window size in the last window the receiver has to validate MIC and send ACK for every received packet.
In other cases(other than the last window), the receiver shall wait until the least CFN of the lost fragments before sending the ACK with bitmap.

example of the expected sequence: (took most part of it from Fig:20 draft-05)

   	 Sender               Receiver
             |-----W=1, CFN=6----->|
             |-----W=1, CFN=5----->|
             |-----W=1, CFN=4--X-->|
             |-----W=1, CFN=3----->|
             |-----W=1, CFN=2--X-->|
             |-----W=1, CFN=1----->|
             |-----W=1, CFN=0----->|
             |<-----ACK, W=1-------|bitmap:11010111
             |-----W=1, CFN=4----->|
             |-----W=1, CFN=2----->|
             |<-----ACK, W=1-------|no bitmap
             |-----W=0, CFN=6----->|
             |-----W=0, CFN=5----->|
             |-----W=0, CFN=4--X-->|
             |-----W=0, CFN=3--X-->|
             |-----W=0, CFN=2--X-->|
             |-----W=0, CFN=7----->|MIC checked
             |<-----ACK, W=0-------|bitmap:11000001
             |-----W=0, CFN=4----->|MIC checked 
             |<-----ACK, W=0-------|bitmap:11100001
	     |-----W=0, CFN=3----->|MIC checked 
             |<-----ACK, W=0-------|bitmap:11100001
	     |-----W=0, CFN=2----->|MIC checked 
	     |<-----ACK, W=0-------|no bitmap
			           (End)

is this the expected behavior? 
if yes, an example in the "Appendix" of the draft and a discussion in "Baseline mechanism" section would be useful (please ignore if it is already planned in 06 version).

Thanks,

-- 
Arunprabhu Kandasamy
arun at ackl.io

2 bis rue de la Châtaigneraie
35510 Cesson-Sévigné 
France 
Phone: +33 (0)2.99.12.24.14

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Aug 2017 13:50:26 +0000

Hello Arun :

I did not see Carles’ answer. I’d not expect this behavior, though. I understand that the case is normally covered by a timer, either on sender (ack always) or receiver (ack on error).

The timer will elapse if the last packet in the window (CFN=0 or CFN=2^N-1 in the first try) is not processed through, regardless of how many other messages are lost, the timer will elapse and one way or another a bitmap is then sent back.

If the last message in the window is received, and the MIC does not match, then the bitmap is provided with the errors. Now: the text expects that the CFN=2^N-1 is not resent at the end of the retried window. So it is hard for the receiver to figure which is the last message of the retry window so as to treat it as the CFN=2^N-1 of the retried last window and ack then. IOW if there is a loss in the second try of the window, the loss will always cause a time out.

We could avoid some of that by indicating the number of the last message in the message CFN=2^N-1 one. If that last message was received, then the missing one is the last 0 in the bitmap before it. Else it is it. Knowing which is the last expected message in the retry window, the receiver now can treat it as the CFN=2^N-1 of the retried window.

Makes sense?

Pascal

From: lp-wan [mailto:[email-masked]] On Behalf Of Arun
Sent: mercredi 16 août 2017 10:50
To: Carles Gomez Montenegro <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>
Subject: [lp-wan] retransmission in the last window

Hi Carles and all,

          Sender               Receiver

             |-----W=1, CFN=6----->|

             |-----W=1, CFN=5----->|

             |-----W=1, CFN=4--X-->|

             |-----W=1, CFN=3----->|

             |-----W=1, CFN=2--X-->|

             |-----W=1, CFN=1----->|

             |-----W=1, CFN=0----->|

             |-----W=1, CFN=4----->|

             |-----W=1, CFN=2----->|

             |-----W=0, CFN=6----->|

             |-----W=0, CFN=5----->|

             |-----W=0, CFN=4--X-->|

             |-----W=0, CFN=3--X-->|

             |-----W=0, CFN=2--X-->|

                            (End)

Thanks,

--

Arunprabhu Kandasamy

arun at ackl.io

35510 Cesson-Sévigné

France

---

From: Arun <[email-masked]>
Date: Tue, 29 Aug 2017 22:03:51 +0200

Hello Pascal,

thanks for jumping in. my comments inline.

On 29/08/2017 15:50, Pascal Thubert (pthubert) wrote:
>
> Hello Arun :
>
>  
>
> I did not see Carles’ answer. I’d not expect this behavior, though. I
> understand that the case is normally covered by a timer, either on
> sender (ack always) or receiver (ack on error).
>
>  
>
> The timer will elapse if the last packet in the window (CFN=0 or
> CFN=2^N-1 in the first try) is not processed through, regardless of
> how many other messages are lost, the timer will elapse and one way or
> another a bitmap is then sent back.
>
>  
>
The draft doesn't specify any timer (other than reassembly timer for the
complete packet) on the receiver side. So the sender is going to timeout
multiple times until MAX_ACK_REQUESTS and then discard the packet
finally because the receiver isn't going to send the ACK. The receiver
doesn't know the ACK request fragment for the last window retransmission.

Solution could be;
 - Start the timer on the receiver;
 - Check MIC for every retransmitted packet that is received;
 - Send ACK:
    - when timeout occurs or
    - when MIC validation passes.

your thoughts?
>
> If the last message in the window is received, and the MIC does not
> match, then the bitmap is provided with the errors. Now: the text
> expects that the CFN=2^N-1 is not resent at the end of the retried
> window. So it is hard for the receiver to figure which is the last
> message of the retry window so as to treat it as the CFN=2^N-1 of the
> retried last window and ack then. IOW if there is a loss in the second
> try of the window, the loss will always cause a time out.
>
Agreed.
>
>  
>
> We could avoid some of that by indicating the number of the last
> message in the message CFN=2^N-1 one. If that last message was
> received, then the missing one is the last 0 in the bitmap before it.
> Else it is it. Knowing which is the last expected message in the retry
> window, the receiver now can treat it as the CFN=2^N-1 of the retried
> window.
>
We need some additional bits to indicate this number?  can you please
elaborate?
>
>  
>
> Makes sense?
>
>  
>
> Pascal
>
>  
>
> *From:*lp-wan [mailto:[email-masked]] *On Behalf Of *Arun
> *Sent:* mercredi 16 août 2017 10:50
> *To:* Carles Gomez Montenegro <[email-masked]
> <mailto:[email-masked]>>
> *Cc:* lp-wan <[email-masked] <mailto:[email-masked]>>
> *Subject:* [lp-wan] retransmission in the last window
>
>  
>
> Hi Carles and all, 
>  

-- 
Arunprabhu Kandasamy
arun at ackl.io

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 30 Aug 2017 19:39:11 +0200

Hi Arun, Pascal,

Thanks to both for triggering this discussion, and sorry for the late
response (I was in vacation).

There is new text in the github working version (not in -05) that touched
a bit on this matter, but I think that Arun's proposal below is much
better defined.

>     - when MIC validation passes.

So this means that there would be a timer on the receiver side that would
be started for the first time upon reception of the fragment with
FCN=2^N-1.

On the other hand, we need to add that the "ACK Always Timer" (which is
defined for the fragment sender) will not be used any more for the current
IPv6 packet after an ACK for the last window of the IPv6 packet is
received by the fragment sender.

If there is agreement, we can add this mechanism in -06.

Thoughts?

Thanks,

Carles

>> *Sent:* mercredi 16 aoÃ»t 2017 10:50
>> Per my understanding, this is bit different than the retransmission
>> behavior that is observed in non-last window.
>> Since there can be lesser number of fragments than the window size in
>> the last window the receiver has to validate MIC and send ACK for every
>> received packet.
>> In other cases(other than the last window), the receiver shall wait
>> until the least CFN of the lost fragments before sending the ACK with
>> bitmap.
>>
>> if yes, an example in the "Appendix" of the draft and a discussion in
>> "Baseline mechanism" section would be useful (please ignore if it is
>> already planned in 06 version).
>>
>> Thanks,
>>
>> --
>> Arunprabhu Kandasamy
>> arun at ackl.io

---

From: Arun <[email-masked]>
Date: Wed, 30 Aug 2017 23:20:04 +0200

Hi Carels,
I agree.
just a thought:

We need to reset the timer (on receiver) for ACKs (with bitmap) sent
after 2^N-1?
Also, we don't have to maintain MAX #of timeouts for this timer as it
can be superseded by reassembly timeout.

regards,

-- 
Arunprabhu Kandasamy
arun at ackl.io