Imported from previous forum
Page 4 of HFT Intro v02.ppt under “Scope of working group” states
-
Session - simple session protocol seperate from Business information.
-
Underlying Protocols - don’t assume IP but state nature of service required
My question :- - were these not covered as part of FIXT.1.1 + FIX.5.0 release which as per FIXT 1.1 Session Protocol Specification at http://fixprotocol.org/specifications/FIXT.1.1 states “Under the TI framework the FIX Session Protocol and the FIX Protocol (the application layer messages) have been separated. This allows FIX Protocol messages to sent via any appropriate transport technology (e.g. MQ, WS-RX, message bus) in addition to the FIX Session Protocol.”
Have I misunderstood the scope of this working group ?
Mahesh,
not sure I understand what you are suggestion here, but let me try to explain how I interpret this aspect of the wg scope.
As the quote says, TI is a framework. We may use all, part, of or none of the framework depending on our analysis.
Specifically, I believe that the Session protocol needs to be very light-weight to minimize session level state overhead and should be separated from the business part of each PDU. We will need to support underlying protocols that are connectionless in order to provide higher scalability by minimizing transport connection state overhead.
Re your question if you have misunderstood the scope, I don’t have sufficient information to answer that question 
How do you see TI being applied fo HFT?
Best,
Rolf
Page 4 of HFT Intro v02.ppt under “Scope of working group” states
Session - simple session protocol seperate from Business information.
Underlying Protocols - don’t assume IP but state nature of service required
My question :- - were these not covered as part of FIXT.1.1 + FIX.5.0 release which as per FIXT 1.1 Session Protocol Specification at http://fixprotocol.org/specifications/FIXT.1.1 states “Under the TI framework the FIX Session Protocol and the FIX Protocol (the application layer messages) have been separated. This allows FIX Protocol messages to sent via any appropriate transport technology (e.g. MQ, WS-RX, message bus) in addition to the FIX Session Protocol.”
Have I misunderstood the scope of this working group ?
Rolf,
We could seperate the work of High Frequency Trading working group into two parts :-
- Optimizing encoding with no changes to FIX Semantics / trading models and workflows. This (sub)group could examine characteristics of available transports, compare wire formats / compression, use Templates to encode and decode, Stored procedures etc.
FIX Tag=Value^ encoding uses TCP as its underlying protocol. We could look at alternate encodings on TCP which offer better performance in the overall context. FAST for market data uses UDP and FIX over FAST uses TCP. By revisiting the question of “why FIX over FAST does not suffice for HFT?” a new “FAST like” encoding suitable for HFT can be developed. There are features of FAST which make it the best encoding for Streaming Market data but these features could be detrimental to HFT performance where order states have a complex relationship between originator, broker / router and the execution venue. Market data is like a monologue whereas Trading is negotiation between systems which goes thru stages. Also many of the repetetiveness present in Market Data streams are not present in Order/Execution workflows. Maybe Opcode Binary Format was not performant for streaming market data but could be suitable for HFT / Order Execution workflows.
- FIX Semantics - Optimizing trading models / workflows without bothering about encoding / transmission, look at new message types for HFT, removal of redundant information from existing message types, Simplyfying FIX Session recovery model, reduce state overhead, etc.
These are two seperate battles and it would be beneficial not to mix these two. FPL should consider creating a new “Transmission encoding and decoding working group” and then this High Frequency Trading working group could concentrate on FIX Semantics / trading models and workflows. Elegant solutions would emerge by seperately considering what needs to be sent and how to best send it.
Just applying divide and conquer
Regards,
K. Mahesh
Mahesh,
not sure I understand what you are suggestion here, but let me try to explain how I interpret this aspect of the wg scope.
As the quote says, TI is a framework. We may use all, part, of or none of the framework depending on our analysis.
Specifically, I believe that the Session protocol needs to be very light-weight to minimize session level state overhead and should be separated from the business part of each PDU. We will need to support underlying protocols that are connectionless in order to provide higher scalability by minimizing transport connection state overhead.
Re your question if you have misunderstood the scope, I don’t have sufficient information to answer that question
How do you see TI being applied fo HFT?
Best,
RolfPage 4 of HFT Intro v02.ppt under “Scope of working group” states
Session - simple session protocol seperate from Business information.
Underlying Protocols - don’t assume IP but state nature of service required
My question :- - were these not covered as part of FIXT.1.1 + FIX.5.0 release which as per FIXT 1.1 Session Protocol Specification at http://fixprotocol.org/specifications/FIXT.1.1 states “Under the TI framework the FIX Session Protocol and the FIX Protocol (the application layer messages) have been separated. This allows FIX Protocol messages to sent via any appropriate transport technology (e.g. MQ, WS-RX, message bus) in addition to the FIX Session Protocol.”
Have I misunderstood the scope of this working group ?
I like this.
Rolf,
We could seperate the work of High Frequency Trading working group into two parts :-
- Optimizing encoding with no changes to FIX Semantics / trading models and workflows. This (sub)group could examine characteristics of available transports, compare wire formats / compression, use Templates to encode and decode, Stored procedures etc.
FIX Tag=Value^ encoding uses TCP as its underlying protocol. We could look at alternate encodings on TCP which offer better performance in the overall context. FAST for market data uses UDP and FIX over FAST uses TCP. By revisiting the question of “why FIX over FAST does not suffice for HFT?” a new “FAST like” encoding suitable for HFT can be developed. There are features of FAST which make it the best encoding for Streaming Market data but these features could be detrimental to HFT performance where order states have a complex relationship between originator, broker / router and the execution venue. Market data is like a monologue whereas Trading is negotiation between systems which goes thru stages. Also many of the repetetiveness present in Market Data streams are not present in Order/Execution workflows. Maybe Opcode Binary Format was not performant for streaming market data but could be suitable for HFT / Order Execution workflows.
- FIX Semantics - Optimizing trading models / workflows without bothering about encoding / transmission, look at new message types for HFT, removal of redundant information from existing message types, Simplyfying FIX Session recovery model, reduce state overhead, etc.
These are two seperate battles and it would be beneficial not to mix these two. FPL should consider creating a new “Transmission encoding and decoding working group” and then this High Frequency Trading working group could concentrate on FIX Semantics / trading models and workflows. Elegant solutions would emerge by seperately considering what needs to be sent and how to best send it.
Regards,
K. MaheshMahesh,
not sure I understand what you are suggestion here, but let me try to explain how I interpret this aspect of the wg scope.
As the quote says, TI is a framework. We may use all, part, of or none of the framework depending on our analysis.
Specifically, I believe that the Session protocol needs to be very light-weight to minimize session level state overhead and should be separated from the business part of each PDU. We will need to support underlying protocols that are connectionless in order to provide higher scalability by minimizing transport connection state overhead.
Re your question if you have misunderstood the scope, I don’t have sufficient information to answer that question
How do you see TI being applied fo HFT?
Best,
RolfPage 4 of HFT Intro v02.ppt under “Scope of working group” states
Session - simple session protocol seperate from Business information.
Underlying Protocols - don’t assume IP but state nature of service required
My question :- - were these not covered as part of FIXT.1.1 + FIX.5.0 release which as per FIXT 1.1 Session Protocol Specification at http://fixprotocol.org/specifications/FIXT.1.1 states “Under the TI framework the FIX Session Protocol and the FIX Protocol (the application layer messages) have been separated. This allows FIX Protocol messages to sent via any appropriate transport technology (e.g. MQ, WS-RX, message bus) in addition to the FIX Session Protocol.”
Have I misunderstood the scope of this working group ?
This is a suggestion I made privately following the first meeting; I think it’s a good idea. I actually suggested three streams:
- One focussing on a better encoding of FIX with no semantics changes.
- One looking at tweaks to existing FIX field and message semantics to improve performance (e.g. removing redundant messages).
- One looking at designing something completely new, from the ground up.
I guess you’ve just elided the final stream, which is fair enough.
Mahesh, I fully agree that separation of concerns is important. I see two reasons for this:
- it will allow more parallelism in development,
- it will allow us to have people with different skill sets focus on what they do best.
We will need to do end-to-end testing though as different combinations interact in non-intuitive ways.
We observed strange results during development of FAST. when analyzing the root cause, we found a resource conflict appearing or disappearing due to somehing that looked like a trivial changes.
More recently in our in-house development of low latency apps we have found that there is a high degree of inter-dependency in resouce utilization from I/O busses, I/O bridges, memory controllers, CPU busses, caches and on-CPU resources like branch target buffers, decode units, store buffers etc.
The combination of very complex hardware platforms and very stringent performance requirements creates a nightmare when it comes to performance verification.
We should avoid putting to much trust in “micro-benchmarks” other than during development and make sure to do system level testing as much as we can when providing baselines that will be used for trade-off analysis.
I think Philip pointed in this direction as well in an earlier post.
/Rolf
- Optimizing encoding with no changes to FIX Semantics
…- FIX Semantics - Optimizing trading models / workflows
…
These are two seperate battles and it would be beneficial not to mix these two. FPL should consider creating a new “Transmission encoding and decoding working group” and then this High Frequency Trading working group could concentrate on FIX Semantics / trading models and workflows. Elegant solutions would emerge by seperately considering what needs to be sent and how to best send it.
[ original email was from Mark Reece - mark.reece@hsbcib.com ]
Rolf, I agree with the testing concerns. We should develop a methodology for testing and proving performance. It might start with off-the-wire capture of inbound and outbound message pairs to determine the latency with an agreed application which takes the incoming message and builds the outgoing message.
Of course, there will need to be a range of messages. The application will need to be flexible. And the sample size agreed. But a standard measurement platform could be agreed.
Beyond that, it would be important to be able to run the same tests on different configurations. 1G/10G/40G/etc is an obvious variable. But there could also be different generations of Intel CPUs, non-Intel CPUs and various other technologies (GPUs, FPGAs, etc). All of these could affect the trade offs likely to be made in the encoding approach.
Also, I very much agree with the divide and conquer approach. I think there is at least as much mileage in providing the option to remove tags - the execution report is a prime example of this.
Regards, Mark
Mahesh, I fully agree that separation of concerns is important. I see two reasons for this:
- it will allow more parallelism in development,
- it will allow us to have people with different skill sets focus on what they do best.
We will need to do end-to-end testing though as different combinations interact in non-intuitive ways.
We observed strange results during development of FAST. when analyzing the root cause, we found a resource conflict appearing or disappearing due to somehing that looked like a trivial changes.
More recently in our in-house development of low latency apps we have found that there is a high degree of inter-dependency in resouce utilization from I/O busses, I/O bridges, memory controllers, CPU busses, caches and on-CPU resources like branch target buffers, decode units, store buffers etc.
The combination of very complex hardware platforms and very stringent performance requirements creates a nightmare when it comes to performance verification.
We should avoid putting to much trust in “micro-benchmarks” other than during development and make sure to do system level testing as much as we can when providing baselines that will be used for trade-off analysis.
I think Philip pointed in this direction as well in an earlier post.
/Rolf
- Optimizing encoding with no changes to FIX Semantics
…- FIX Semantics - Optimizing trading models / workflows
…
These are two seperate battles and it would be beneficial not to mix these two. FPL should consider creating a new “Transmission encoding and decoding working group” and then this High Frequency Trading working group could concentrate on FIX Semantics / trading models and workflows. Elegant solutions would emerge by seperately considering what needs to be sent and how to best send it.