New message types to measure end to end round trip time

, ,
1

Imported from previous forum

2

To measure the “end-to-end” round trip time including the time within both the infrastructures - Buy side and Sell side, i.e. the time for a complete round trip :-

BuySide application - BuySide FIX Engine - FIX Network - SellSide FIX Engine - SellSide application

Lets call these PingRequest and PingResponse

I do not know of standard message types at present in FIX.5.0SP2 to provide this functionality. The PingRequest message can be initiated by either side - Buy or Sell.

Tag 112 TestReqID can be used to correlate the PingRespone to a PingRequest

A new Tag (RequestMessageReceiptTime) can be added in the PingResponse to indicate the time at which the PingRequest was received.

This was discussed in detail in the General Q/A forum at

http://fixprotocol.org/discuss/read/66643a45

Regards,
K. Mahesh

3

[ original email was from Clive Browning - clive.browning@rapidaddition.co.uk ]

Hi Mahesh

This is interesting, but it is complex with many scenarios… the depth into the sellside application layer may depend on the message type and parameters of that message.

Clive

To measure the “end-to-end” round trip time including the time within
both the infrastructures - Buy side and Sell side, i.e. the time for a
complete round trip :-

BuySide application - BuySide FIX Engine - FIX Network - SellSide FIX
Engine - SellSide application

Lets call these PingRequest and PingResponse

I do not know of standard message types at present in FIX.5.0SP2 to
provide this functionality. The PingRequest message can be initiated by
either side - Buy or Sell.

Tag 112 TestReqID can be used to correlate the PingRespone to a
PingRequest

A new Tag (RequestMessageReceiptTime) can be added in the PingResponse
to indicate the time at which the PingRequest was received.

This was discussed in detail in the General Q/A forum at

http://fixprotocol.org/discuss/read/66643a45

Regards,
K. Mahesh

4

The application level messages NetworkCounterpartySystemStatusRequest and NetworkCounterpartySystemStatusResponse could be extended to include round trip information. Bilateral agreement could define how far into the sell side application the request should go.

Apart from timestamp field(s), the field NetworkRequestType would need another value, e.g. “Roundtrip” to indicate this type of request.

Another option would be an extension of UserRequest and UserResponse messages with a new value for UserRequestType. This could be used to define a “longer” path, e.g. all the way into the core application of the sell side (or exchange) whereas the NetworkCounterpartySystemStatusRequest only goes into the first (FIX) gateway of the sell side (or exchange). This should be left to bilateral agreement and defined within the rules of engagement.

Regards,
Hanno.

To measure the “end-to-end” round trip time including the time within
both the infrastructures - Buy side and Sell side, i.e. the time for a
complete round trip :-

BuySide application - BuySide FIX Engine - FIX Network - SellSide FIX
Engine - SellSide application

Lets call these PingRequest and PingResponse

I do not know of standard message types at present in FIX.5.0SP2 to
provide this functionality. The PingRequest message can be initiated by
either side - Buy or Sell.

Tag 112 TestReqID can be used to correlate the PingRespone to a
PingRequest

A new Tag (RequestMessageReceiptTime) can be added in the PingResponse
to indicate the time at which the PingRequest was received.

This was discussed in detail in the General Q/A forum at

http://fixprotocol.org/discuss/read/66643a45

Regards,
K. Mahesh