PUBLIC COMMENT PERIOD - FIX Performance Session Layer (FIXP) - Release Candidate 1

, , , ,
1

Imported from previous forum

2

This proposal from the High Performance Working Group provides a new FIX session layer for high performance. FIX Performance Session Layer (FIXP) is a “lightweight point-to-point protocol” introduced to provide an open industry standard for high performance computing requirements currently encountered by the FIX Community.

The technical standard proposal for the first release candidate for the FIX Performance Session Layer can be found here: http://www.fixtradingcommunity.org/pg/structure/tech-specs/fix-performance-session-layer

The proposal is following the technical standards review process described in the document found here:
http://www.fixtradingcommunity.org/mod/file/view.php?file_guid=46944

This release candidate now enters a public comment period in which public review and feedback is encouraged. The public comment period will run for a period of 90 days beginning on Friday the 31st of October.

Please post feedback, comments, and questions as replies to this discussion thread.

3

I suggest to revisit the current design of message type IDs which are subject to ranges (Chapter 3.3.1) and have pre-defined values. It should be possible to have all values defined in a schema whereby there could be separate schemas for session and application messages. Pre-defined values as part of the FIX Repository should be available for use cases where there is no such schema. All FIX application messages have a numeric component ID in the FIX Repository which could be re-used for this purpose. A schema is required as soon as the application wants to use templates and have the flexibility to define more than one variant of a FIX message type, for example multiple templates reflecting the different usages of the FIX ExecutionReport (e.g. confirm order add, convey partial fill etc.).

Applied/Not Applied are defined as application messages but have message type IDs in the range of session messages. If they belong to FIXP then they should be referred to differently to avoid confusion with “real” application messages. They relate to the application level but are provided on the session level to support idempotent flow (Chapter 3.12).

4

The FIXP spec should be explicit about behavior when NextSeqNo on an Establish or Sequence message is lower than the receiver expected. It should ignore subsequent application messages as duplicates until the expected sequence number is reached.

When a gap is detected on a recoverable or idempotent flow, the spec states that the receiver should send back a RetransmitRequest or NotApplied message. However, it does not state what it should do with subsequently received application messages. It should assume that current sequence number now follows the reported gap and accept those messages. (It is up to the sender to fill the gap on a recoverable flow, but it is not obligated to so on an idempotent flow.)

In general, the spec should distinguish required versus recommended or optional behavior by using RFC 2119 terminology (must, must not, may, should, etc.).

5

Don, you say “It is up to the sender to fill the gap on a recoverable flow, but it is not obligated to so on an idempotent flow.” On the first bit, for clarification, do you agree that it is the receiver who identifies the gap to the sender by sending him a retransmit request and THEN it is up to the sender to decide whether to fill the gap or terminate the session?

On the second bit, the spec says in Chapter 3.10 that sending a retransmit request to the sender of an idempotent or unsequenced flow is a protocol violation. Hence the sender has no knowledge about a gap in an idempotent flow unless there is a protocol violation. That implies to me that “not obligated” is not correct as there is no option to fill the gap in such a case, even if the sender wanted to. Or should a retransmit request be allowed for an idempotent flow but not for an unsequenced flow?

6

Hanno, to your first point, it seems that the spec as written does not rule out this scenario: a party receives a RetransmitRequest, but instead of retransmitting the messages, it terminates the session. Then it re-establishes the sesssion with NextSeqNo set to the number following the gap. This is functionally equivalent to a gap fill in FIXT. To me, this violates the spirit of a recoverable flow, but we should address the point in the spec.

On the second point, my previous post was ambiguous since I took a shortcut to cover both recoverable and idempotent flows in once sentence. To clarify: the receiver notifies the sender of a gap in both flow types. It is done with RetransmitRequest for a recoverable flow and NotApplied message for an idempotent flow. The difference is that the sender is obligated to retransmit messages on a recoverable flow while it is at the sender’s discretion on an idempotent flow.

RetransmitRequest is only valid for a recoverable flow, NotApplied is only valid for idempotent flow, and neither is valid for an unsequenced flow.

7

Requirements for FIXP based on discussion in HPWG Application Level Market Data subgroup:

Some sessions, such as market data or reference data, publish unidirectional flows of application messages even though the underlying transport (like TCP) is bidirectional. On Negotiate and NegotiationResponse, FIXP should provide for a flow type of NONE in addition to Unsequenced, Idempotent, and Recoverable flows. On such a session, the subscriber party would be able to send session messages but not application messages. It could, for example, send RetransmitRequest if the reverse flow is recoverable.

In other cases, the transport itself is unidirectional, such as UDP multicast. Session initiation cannot depend on request/response behavior, preventing use of NegogiationResponse and EstablishmentAck. Likewise, there is no way to return FinishedReceiving at the end of a recoverable flow. FIXP should allow unidirectional session establishment and termination.

8

Retransmission requirements for FIXP based on discussion in HPWG Application Level Market Data subgroup:

  • For performance reasons, a party may impose a limit to the message count of a RetransmitRequest. Typically, this is documented out-of-band, but it might be useful to deliver such limits in-band in session negotiation.

  • For multicast market data, a separate recovery channel is often provided. With FIXP, the SessionId in RetansmitRequest and Retransmission should be the UUID of the original publishing channel.

  • Possible errors in recovery: Sequence numbers out of range in RetransmitRequest results in session termination with code ReRequestOutOfBounds, according to RC1 spec. The working group questioned whether this is appropriate for out-of-band recovery. Rather, it might be better to return an explicit rejection without terminating the session. Furthermore, a request sequence range may be valid but the service may no longer have the messages available in its storage. There is no way to report this to the requester currently. Also, if a limit is imposed as mentioned above, there should be an explicit error to report that it was exceeded even though the requested range was valid.

  • Market data retransmissions may be multicast to all interested listeners. If the event of a brief network fault, several subscribers would request similar ranges for retransmissions. For performance reasons, the publisher could consolidate the requests. Then listeners need to filter for retransmissions that they are interested. However, the RequestTimestamp field of Retransmission would be useless, since the retransmission is not based on a single user’s request. Several solutions are possible, but one would be to create a special value for RequestTimestamp that indicates it is in response to multiple requests.

9

The next draft of the FIXP session protocol should address business use cases and provide guidance for matching technical features to business needs. Common use cases for order flows are:

  • Multiplexing of messages from/to different traders or trading systems/algos on a shared session. What are the benefits and drawbacks of multiplexing versus using multiple non-multiplexed sessions?

  • Drop copy: multiple observers receive the same notifications of executions. Does FIXP provide a solution to risk control, auditing and order management needs in addition to order originators?

  • We should discuss out-of-band recovery solutions. The market data working group has done a nice job of enumerating scenarios for market data recovery. We need equivalent guidance for order flows.

Technical questions to be addressed:

  • What are the benefits and issues of a datagram oriented transport versus TCP stream under FIXP? What are the network management implications?

  • In general, how can FIXP be supported operationally? Obvious issues are that binary session messages are not humanly readable, unlike tag=value, and session IDs are transient in FIXP, not permanent business entity identifiers.

  • Based on recent events, we cannot avoid providing guidance on security considerations for authentication, non-repudiation and privacy.