Subject: [6lo] recoverable fragments: should we allow the receiver to send asynchronous acks

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 May 2019 13:01:32 +0000

Dear all:

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.
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.

What do you all think?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 May 2019 09:47:05 -0400

Pascal Thubert (pthubert) <[email-masked]> 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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 May 2019 14:24:57 +0000

Hello Michael
 
> 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. 

> 1) Not re-inventing TCP is important.

Yep. We're not there yet : )

>    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-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-