Subject: Re: [lp-wan] comments on the LPWAN fragmentation

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Apr 2017 16:54:08 +0000

One more suggestion:

There seems to be no way for either end to terminate the exchange in the middle.

If the sender decides to terminate, it could be sending an all 1s, but then we'd need an indication before the MIC to say abort. That's probably a good idea anyway.
If the receiver decided to terminate, it would signal that with an ack and a bitmap that is all zeroes.

What do you think?

Pascal

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: jeudi 30 mars 2017 12:00
To: lp-wan <[email-masked]>
Subject: [lp-wan] comments on the LPWAN fragmentation

Dear authors:

Please find some questions and suggestions:

- introduce the assumptions early in the doc (e.g. no reordering in the network)
- there could be a section explain what the tools are, e.g. CFN, ACK, Bitmap, before we use them
- can there be multiple fragmented packets in parallel (how so) ? 
- Can we interleave non fragmented packets?
- discussion on timeouts is probably missing here and there
- discussion on what the modes are could be expressed as a matrix with X ==  windowed or not (that's CFN=1 or more), and Y == type of acknowledgement (none, on-error, always). And in that matrix, it would help to figure which modes are available, and then have section to explain the pro/con, possible mitigation of the cons and applicability of each mode.

What do you think?

Pascal

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 3 Apr 2017 20:10:44 +0200

Hi Pascal,

Thanks a lot for your comments.

Yes, all these suggestions should help clarify and complete the existing
text on fragmentation.

The plan would be to address all of these comments in the next SCHC draft
revision, along with updates based on feedback received in Chicago.

Cheers,

Carles

> - discussion on what the modes are could be expressed as a matrix with X
> ==  windowed or not (that's CFN=1 or more), and Y == type of
> acknowledgement (none, on-error, always). And in that matrix, it would
> help to figure which modes are available, and then have section to explain
> the pro/con, possible mitigation of the cons and applicability of each
> mode.
>
> What do you think?
>
> Pascal
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 3 Apr 2017 20:36:33 +0200

Hi Pascal,

> If the sender decides to terminate, it could be sending an all 1s, but
> then we'd need an indication before the MIC to say abort. That's probably
> a good idea anyway.

I agree that the indication to terminate requires some special Rule ID
code (or some Rule ID space) to signal that the sender does want to abort.
Using CFN=11..1 in this case can be useful as some extra confirmation of
the sender's willingness to abort.

CFN=11..1 alone without further abort signals (or Rule ID space stolen for
that purpose) might still trigger feedback from the receiver and have the
receiver waiting for possible retries in the reliable modes...

> a bitmap that is all zeroes.

My concern for this is: what happens if a receiver does not receive any
fragment for a given IPv6 packet (hence the bitmap would be all zeroes),
but it does *not* want to abort?

I think that, in order to distinguish one situation from the other, we
need some special Rule ID for it.

Thoughts?

Thanks,

Carles

---

From: Ivaylo Petrov <[email-masked]>
Date: Mon, 3 Apr 2017 19:39:34 -0500

Hi Carles,

​Do you have any particular examples in which the receiver will know that
she needs to send an ACK with bitmap all zeroes? Normally if you don't
receive any fragment, you don't know that you need to acknowledge (with
bitmap set to all 0). The only case I currently see where that could be
useful is if the receiver needs to acknowledge a window and a timer has
expired before the receiver has received any fragment from the window (if I
understood correctly, only the last fragment from the packet will have CFN
set to 111...1, so the receiver could know that she expects more data). At
the same time I don't know who should be the proactive part in such case -
the sender failing to receive an ACK to resend the complete window or the
receiver...

Thanks,
Ivaylo   ​

2017-04-03 13:36 GMT-05:00 Carles Gomez Montenegro <[email-masked]>:

> > If the receiver decided to terminate, it would signal that with an ack
> and
> > a bitmap that is all zeroes.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Apr 2017 06:07:40 +0000

Hello Carles

I agree that rule is can do the trick in both directions.

 I do not follow you, though, on the 
Problem with all zeros ack: The receiving device can only answer positively once it has received something so a positive response must have a bit set in it.

Take care,

Pascal

> Le 3 avr. 2017 à 20:36, Carles Gomez Montenegro <[email-masked]> a écrit :
> 
> Hi Pascal,
> 
>> One more suggestion:
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Apr 2017 06:14:53 +0000

Agreed, Ivaylo.

Note that both sides may have their reason to abort, like lack of memory, higher priority stuff to do.

Also that depending in the direction, it might be better that the timeout/abort happens on source or destination so we should support both.

Finally that anything that involves a continuation should have a timer associated, on both sides, so that resources are never wasted forever. For each timeout there should be an action in the standard, be it only clean up and go.

Regards,

Pascal

Le 4 avr. 2017 ? 02:40, Ivaylo Petrov <[email-masked]<mailto:[email-masked]>> a ?crit :

Hi Carles,

?Do you have any particular examples in which the receiver will know that she needs to send an ACK with bitmap all zeroes? Normally if you don't receive any fragment, you don't know that you need to acknowledge (with bitmap set to all 0). The only case I currently see where that could be useful is if the receiver needs to acknowledge a window and a timer has expired before the receiver has received any fragment from the window (if I understood correctly, only the last fragment from the packet will have CFN set to 111...1, so the receiver could know that she expects more data). At the same time I don't know who should be the proactive part in such case - the sender failing to receive an ACK to resend the complete window or the receiver...

Thanks,
Ivaylo   ?

2017-04-03 13:36 GMT-05:00 Carles Gomez Montenegro <[email-masked]<mailto:[email-masked]>>:
Hi Pascal,

Thoughts?

Thanks,

Carles

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 4 Apr 2017 14:57:54 +0200

Hi Pascal,

> I agree that rule is can do the trick in both directions.

OK!

> Problem with all zeros ack: The receiving device can only answer
> positively once it has received something so a positive response must have
> a bit set in it.

Yes, my previous text was a bit rushed, but I think Ivaylo's example is
good to illustrate what I was trying to say.

In any case, yes, some Rule ID space will need to be used for this purpose
(in any direction).

Thanks, (and thanks Ivaylo!),

Carles

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 5 Apr 2017 12:38:44 +0200

Hello,

Do you mean an Abort-ACK with a Rule-ID that means Abort?

Ana

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Apr 2017 11:51:16 +0000

Hello Ana :

The rule can be abort, and can be triggered by both sides asynchronously, though maybe it takes a packet in to be able to send a packet out so one side may not be able to transmit it at any time it wants (e.g. in case of time out it may have to wait some additional time).
Like other messages, we may want an abort-ack, or not, depending if the device has something useful to do with the confirm. I suggest that the abort rule is followed by fields that indicate what the error is, the datagram tag if there is one, and whether it is an ack.

I’m wondering is the CoAP piece also needs abort?

Take care,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ana Minaburo
Sent: mercredi 5 avril 2017 12:39
To: Carles Gomez Montenegro <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] comments on the LPWAN fragmentation

Hello,

Ana

On Tue, Apr 4, 2017 at 2:57 PM, Carles Gomez Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal,

OK!

Carles

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 12 Apr 2017 15:27:51 +0200

Hello,

I’m agree about this abort-ruleID, for instance we need to define the structure of this context rule and we need to define the specific rule-ID to be used. 

It could be a generic abort rule to be used in any protocol? 

Ana

> On 05 Apr 2017, at 13:51, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ana :
>  
> On Tue, Apr 4, 2017 at 2:57 PM, Carles Gomez Montenegro <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Pascal,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
>