New Feature: Freeze/Thaw section 4.12.2 TRANSMISSION OPPORTUNITY PROCEDURES

[MTI-twalker]

Per section 4.12.2 TRANSMISSION OPPORTUNITY PROCEDURES

4.12.2.1 On notification of the end of an opportunity to transmit to a specified remote CFDP
entity, the CFDP entity shall ‘freeze’ transmission for all transactions for which it is the
sending entity and the specified remote entity is the receiving entity.
4.12.2.2 The freezing of transmission for a transaction shall have the same effects as
suspension of that transaction by the sending entity (see 4.11.2.6), except that no
Suspended.indication shall be issued and the transaction shall not be considered suspended.
4.12.2.3 On notification of the start of an opportunity to transmit to a specified remote
CFDP entity, the CFDP entity shall ‘thaw’ transmission for all transactions for which it is the
sending entity and the specified remote entity is the receiving entity.
4.12.2.4 The thawing of transmission for a transaction shall have the same effects as
resumption of that transaction by the sending entity (see 4.6.7.2.1), except that (a) no
Resumed.indication shall be issued and (b) thawing transmission for a suspended
transaction shall have no effect whatsoever.

Would it be possible to add "Freeze" and "Thaw"?

Seems like it wouldnt be too different from suspend/resume with the above exceptions.

[MTI-twalker]

@ryanmelt? @jmthomas?

[ryanmelt]

There is no specification on how to notify the CFDP engine that the opportunities have come or gone. So we would have to make that up and it doesn't seem to provide any value over suspend/resume. Can you not use suspend/resume?

[ryanmelt]

Or is it important that something you have suspended stays suspended, even if a contact starts?

[MTI-twalker]

I believe this is specifically for freeze/thawing which is suspending/resuming all transactions at once (without affecting current suspended transactions) and is based on a contact window so it is aware of that and does not try to send indications.

The workaround I was thinking was to just use a procedure that loops specific transactions for suspend/resuming pre/post contact window. So it is possible to use the current configuration with workarounds to meet our freeze/thaw capability requirement.

I have not totally looked into the implementation to fully write out what needs to be done. Our FSW team is looking to include this implementation and figured since it is part of the bluebook you'd want to have an implementation for it. If that isn't the case we can close this and I can figure something out. We may have some support hours we can use for this? (Not sure if Github is where we should be reaching out or not)

[ryanmelt]

The spec discusses freeze/thaw but it doesn't dictate how to implement it at all.
If we added some new cfdp_freeze, cfdp_thaw api methods, would that work for your use case?

[MTI-twalker]

Yes sorry, I just realized what you were saying in your first reply. The opportunities are a bit vague in the bluebook.

If its up to me, I would think that it depends on the target mapping interface connections. Essentially, if an interface that the target is mapped to disconnects that it freeze's the transactions and then thaws the transactions once it reconnects. OpenC3's only understanding of the connection is at the interface I would think and not a scheduled contact window.

I think that meets the intent of freeze/thaw is that it is resilient to connection loss. Which is why no indication is included in the freeze/thaw events.

[jmthomas]

Great minds think alike because I found this comment in the code already:

openc3-cosmos-cfdp/microservices/CFDP/app/models/cfdp_user.rb

Line 52 in 44791a1

# TODO: Handle freezing transactions if interface disconnects (or target goes unhealthy), and unfreezing if comes back to functional