DICOM: How DIMSE Timeout work on big instances?

Question

My understanding is that the time(out) between two consecutive DIMSE communications (request or response) is DIMSE Timeout.

So, in MWL operation, MWL SCU (establishes the connection and association and) sends the MWL CFind request. SCP should send first response before DIMSE Timeout expires. Similarly, each next response should be sent by SCP before DIMSE Timeout expires.

Similarly, for CStore operation, CStore SCU sends the request and SCP should respond before DIMSE timeout expires. This should happen for each instance sent on that association.

Is my understanding correct?

If yes, then how does this work for big size instances those take long time (more than DIMSE Timeout set) to completely transfer?

For example, CStore SCU is pushing an instance (big size multi frame lets say) which take 1000 milliseconds to transfer completely. DIMSE Timeout on both SCP and SCU is set to 500 milliseconds. What is expected result here? Will SCP or SCU encounter DIMSE Timeout?

Answer 1

A DIMSE C-STORE message for a big object is split into multiple P-DATA packets (PDUs, those are the TCP packets sent through the network). So actually, two timeouts apply:

• The DIMSE timeout. This timeout occurs between two subsequent DIMSE messages
• The PDU timeout. This occurs between two subsequent PDUs.

E.g. for the C-STORE service:

• if the SCP does not send the C-STORE response timely after the request has been completely sent (i.e. all frames transferred) -> DIMSE timeout
• if the SCU does not send the first PDU for the next C-STORE request timely after the response to the previous object has been sent by the SCP -> DIMSE timeout
• if the timespan between 2 subsequent fragments (PDUs) sent by the SCU exceeds the SCP's expectations -> PDU timeout