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

[Martine Lenders <[e-mail]>]

Hi Pascal,

Sorry, I noticed this in your original mail, but forgot to mention it, now
it is also in the draft:

> […] Acknowledgment on the reverse path with a FULL bitmap, and harms a
> short timer to absorb packets that are still in flight for that […]

Do you mean "arms a short timer"?

Best regards,
Martine

Am Mi., 23. Okt. 2019 um 14:52 Uhr schrieb Pascal Thubert (pthubert) <
[e-mail]>:

> Cool : )
>
>
>
> I published 07, please see the diffs.
>
>
>
> All the best;
>
>
>
> Pascal
>
>
>
> *From:* 6lo <[e-mail]> *On Behalf Of *Martine Lenders
> *Sent:* mercredi 23 octobre 2019 14:46
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap
> when datagram is complete?
>
>
>
> Hi,
>
>
>
> Am Mi., 23. Okt. 2019 um 14:43 Uhr schrieb Pascal Thubert (pthubert) <
> [e-mail]>:
>
> Hello Martine
>
>
>
> I meant fragments. It can be expected that a few fragments are still in
> flight after everything is received because of end to end fragment retries
> or L2 ARQ. So the receiver must keep a state to drop them silently. But is
> it gets “too much “ of that it may be an error and the receiver should
> abort the flow.
>
>
>
> That “too much” decision is left to implementation.
>
>
>
> Thank, now it is clearer!
>
>
>
> Regards,
>
> Martine
>
>
>
>
>
>
>
> Regards,
>
>
>
> Pascal
>
>
>
> Le 23 oct. 2019 à 14:29, Martine Lenders <[e-mail]> a
> écrit :
>
> 
>
> 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
>
>