ICS004 Channel Upgrades - In flight packets

[damiannolan]

From reading the specification for ICS004 Channel Upgrades I found there to be no mention of what may happen to any number of packets that may try to be sent or are in-flight at the time the upgrade handshake takes place.

Would it be such that the state of a channel-end would change to UPGRADE_INIT or UPGRADE_TRY for example, and this would cause packet recvs to fail at this point in the ibc-go implementation.

I see the code in ibc-go's SendPacket just ensure the channel is not closed. Do we want to allow SendPacket to still be called when an upgrade takes place, so that it could potentially be relayed post upgrade? And if so, is there any concerns around this?

1. Is there any concerns regarding in-flight packets during a channel upgrade that haven't been explored?
2. I think it could be potentially useful to mention this in the spec either way, that is, if there is no problems regarding this.

Would be interested to hear the thoughts of the team on this? cc. @AdityaSripal
Feel free to ack and close this issue if there is no problem, thanks!

[AdityaSripal]

Great questions @damiannolan

Yes, it is intended that packets in-flight are "paused" until the upgrade is complete. This is to ensure that packet flow cannot happen while the channel is in a temporarily invalid state (e.g. one end is on v1, and the other is on v2). See discussion here: #621 (comment) (this is for connection upgradability but analogous rationale for channels)

Is there any concerns regarding in-flight packets during a channel upgrade that haven't been explored?

• Once the upgrade completes, the packet flow of in-flight packets can resume. It's possible that some in-flight packets will have reached their timeout because of the upgrade but that's totally fine.
• At the channel level, upgrades can only change certain channel struct fields along with the application packet processing logic. So it is possible after an upgrade, in-flight packet data is no longer parsable. This again is not a big issue, since it will result in error acks on the sent packets. If application developers want to avoid this, they should make their upgrades backwards compatible.

I think neither of these are issues but we should definitely discuss this in the spec so that developers are aware of possible

Do we want to allow SendPacket to still be called when an upgrade takes place, so that it could potentially be relayed post upgrade?

I do believe this is still useful since at least then we are only delaying the relaying and processing of packets. Packets can still get queued and then sent out once the upgrade completes. This is a useful feature I believe, and is in-line with what we already have with optimistic sends during the initial channel handshake.

The one issue here, is of course it's possible that some of these SendPackets will be unparsable after the upgrade but this is again an issue we already have and it is neither catastrophic and app developers can choose to avoid it if they want.

This should also be discussed in the spec so that it is visible to app developers.

TL;DR: There aren't issues wrt channel upgradability, but we should document the effect of upgrades on in-flight packets in the spec

[damiannolan]

Thanks for the detailed response @AdityaSripal

[crodriguezvega]

Closed by #967.