Re: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap when datagram is complete?

[Martine Lenders <[e-mail]>]

Hi Pascal,

Am Mo., 21. Okt. 2019 um 18:14 Uhr schrieb Pascal Thubert (pthubert) <
[e-mail]>:

> Hello Again
>
>
>
> I reread the text and it appears that the receiver operation is too
> implicit. I suggest to add this in the last fragment processing:
>
>
>
>     When all the fragments are received, the receiving endpoint
> reconstructs
>
>     the packet, passes it to the upper layer, sends a RFRAG Acknowledgment
> on
>
>     the reverse path with a FULL bitmap, and harms a short timer to absorb
>
>     packets that are still in flight for that datagram without creating a
> new
>
>     state and abort the communication if it keeps going.
>
>
>
> Does that help?
>

If this goes somewhere in section 6, yes I think that makes it far more
understandable.


> Note that there’s room for an implementation to decide if it absorbs
> silently a few packets and for how long, and when it decides to reset the
> flow. The all 1 (to be renamed throughout to FULL)  does not help more than
> the reset.
>

By packets you mean fragments or reassembled datagrams. I don't really
understand what you mean by that.

Best regards,
Martine


>
>
> Pascal
>
>
>
>
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* lundi 21 octobre 2019 17:29
> *To:* Martine Lenders <[e-mail]>; [e-mail]
> *Subject:* RE: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap
> when datagram is complete?
>
>
>
> Sorry I missed that Martine!
>
>
>
> The ALL 1s was already sent when the last fragment was received. This text
> happens later.
>
>
>
> It is supposed to have been processed along the way back. The receiving
> end node maintains a state for a “short” time after the message processing
> to absorb packets that may still be in flight. During that “short” time it
> is capable to recognize redundant packets and drop them as opposed to
> create a new state and expect the full fragment. For legitimate packets
> still in flight the good thing would be to stay silent. If the Ack with a
> FULL (All 1s) bitmap was lost then sending it again would be OK as you
> point out.
>
>
>
> But there might also be error conditions, like a weird situation that the
> FULL bitmap did not fix on its way back where the sender keeps sending. If
> the FULL bitmap failed then retrying it may fail again. The reset is a
> clearer indication to drop everything regardless and move to the next.
>
>
>
> Works? Should we massage text?
>
>
>
> All the best
>
>
>
> Pascal
>
>
>
> Am Di., 1. Okt. 2019 um 16:31 Uhr schrieb Martine Lenders <
> [e-mail]>:
>
> Hi,
>
>
>
> draft-ietf-6lo-fragment-recovery states in section 6.3
>
>
>
> [the] might need to abort the process of a fragmented packet for internal
> reasons, for instance if it […] considers that this packet is already fully
> reassembled and passed to the upper layer. In that case, the receiver
> SHOULD indicate so to the sender with a NULL bitmap in a RFRAG
> Acknowledgment.
>
>
>
> The given example seems to me the perfect instance to set a FULL bitmap
> instead. There is no other instance were a FULL bitmap is specified to be
> sent, except for the case that the datagram incidentally fills out the
> whole value space of the sequence number field.
>
>
>
> Or am I missing something?
>
>
>
> Kind regards,
>
> Martine
>
>