Hi, Am Mi., 23. Okt. 2019 um 14:43 Uhr schrieb Pascal Thubert (pthubert) < [email protected]>:
> 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 <[email protected]> a > écrit : > > > 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
