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?
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.
Pascal
From: Pascal Thubert (pthubert)
Sent: lundi 21 octobre 2019 17:29
To: Martine Lenders <[email protected]>; [email protected]
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
<[email protected]<mailto:[email protected]>>:
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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
