Hi Pascal, Am Mo., 21. Okt. 2019 um 18:14 Uhr schrieb Pascal Thubert (pthubert) < [email protected]>:
> 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 <[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]>: > > 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
