Should there be ACKs for data or should data only be sent in Prepare packets?

[interledgerjs]

Should there be ACKs for data or should data only be sent in Prepare packets?

[sharafian]

I think that sounds reasonable, because then we can do one pass to validate the data and then if that succeeds do another pass to hand off data and moneyd to streams, rather than having to partially apply the packet's operations in the case where its rejected.

I suspect that if rejects ACK data it would also cause some confusing cases when we bring in logic around stream closing

[sharafian]

Given that the rules for data are different from the rules for money (successfully sending data while rejecting money is a reasonably common case), I think it makes sense to diverge from QUIC here and ACK on a per-frame basis

[emschwartz]

Actually rejecting money or data should only happen if one side isn't respecting the flow control messages. Both sides should tell the other how much money and data they are willing to accept, and they should tell the other side right away if the limits increase.

[emschwartz]

I think we should have it only send data on prepares and use ILP fulfills / rejects as ACKs. It simplifies the protocol and if we ever wanted to allow data to be sent in response packets we could add additional frames to handle this later.

Now the question is whether we should count ILP Reject packets that come from the receiver (and are authenticated so we know the prepare really made it to the receiver) as ACKs or NACKs. The data definitely got to the receiver, but they are rejecting the packet. Are they rejecting the data? I'm leaning towards saying that any reject is a rejection of the money as well as the data and the data should be resent. Thoughts?

[emschwartz]

This question has been answered for now. We'll track the implementation in #12