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?
> 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.
2) Perhaps the question is better turned around: what should the sender do if
an ACK arrives without having been asked for?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
