Hello Michael > Pascal Thubert (pthubert) <[email protected]> wrote: > > During the review by Laurent, a question came up on whether the receiver > > could asynchronously send RFRAG Acks e.g., to transport an ECN > > indication. > > So would the ACKs be out of order, acknoledging fragment n+2 while still > waiting for fragment n? Or would the acks be repeat of a previous ack (n-1), > indicating congestion, and likely signaling that fragment n got lost?
An ack has the full bitmap of all that's received so far. That would be the case there too. So it's a brand new ack, just unsolicited. It is important for the sender to know all that's received to determine the max number of fragments in flight. So I agree that an unsolicited ack may be confusing, e.g. if the sender sent it all and only asks for an ack in the end, then it may retry all that's en-route at the time the ack is emitted. But then, it could find that the sequence for which is sent an ack request is not acknowledged so it would not take that action. > > > At the moment, the sender is in full control and the ack is only sent > if the > > sender asks for it. Laurent indicates that asynchronous Ack could > generate > > more collisions and make the problem worse. > > 1) Not re-inventing TCP is important. Yep. We're not there yet : ) > 2) Perhaps the question is better turned around: what should the sender do if > an ACK arrives without having been asked for? Interesting, mostly in the light of your point above. I guess that it should not infer that the packets sent after most recent acknowledged sequence are lost; they may just be still in flight. The sender retries the sequences in a round robin to leave a chance for the next ack to ack packets en-route at the time the previous ack was issued. It may reopen the window if the ack confirms reception of new packets, and tune the window size if ECN. Since the packets are not sequenced, it might be that after a few tries, the sender gets an ack that indicates that the receiver does not have the packet for which a retry was en-route at the time the ack was sent. So I guess that there must be a round trip between each retransmission of a packet. Unclear how to achieve that. Pascal > -- > Michael Richardson <[email protected]>, Sandelman Software Works - > = IPv6 IoT consulting =- _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
