[lp-wan] Limiting fragment retries in ACK on Error (Re: I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.txt)

["Carles Gomez Montenegro" <[e-mail]>]

Dear LPWANners,

This is a heads-up on the discussion item that was remaining after
Dominique's review of SCHC fragmentation.

Our exchange on this topic was as follows:

>>> * Section 9.2: MAX_FRAG_RETRIES is described for the Window mode - ACK
>>> "always". For completeness, the same text should be repeated for the
>>> Window mode - ACK on error.
>>
>>I think your proposal is one possible approach.
>>
>>Another approach, which is the current one in the draft (and may need to
>>be discussed) is that in "ACK on error", the maximum number of
>>retransmission rounds will be controlled by the receiver by means of
>>MAX_ACKS_PER_WINDOW, while the sender will retransmit any fragments
>>reported to be lost in an ACK. Otherwise, in some situations, the
>> receiver
>>may unnecessarily send ACKs while the sender will not reply (with
>> fragment
>>retries) to those if it has reached its maximum number of retries. The
>>receiver does not necessarily know the MAX_FRAG_RETRIES value of the
>>sender.
>>
>>Thoughts?
>
> I understand how it works if every node is nice and plays by the rule.
> But I picture myself implementing the sender code and writing the "repeat
> until" loop where the exit condition is totally under the control of
> the other node.
> That makes me shiver.
> Isn't this an avenue for a DOS attack, with a node handing its energy and
> radio bandwidth over to another node?
> I'm sure implementers will want to add a local stop condition to this
> loop anyway.
> But maybe it does not belong to the protocol specification.
> What do others think?

A question we may consider is:

- Should MAX_FRAG_RETRIES be defined as well in Window mode - ACK on
error, or should the maximum number of fragment retries (in ACK on error)
be handled only at the implementation level and not defined in the SCHC
specification?

Please let us know your thoughts!

Thanks,

Carles