Imported from previous forum
Hello!
I’m a thesis worker doing my work regarding flow control in (distributed) FIX/FAST systems and more specifically, evaluating how to regulate market data.
Naturally, I’m interested in the throttling proposal by FPL found in http://www.fixprotocol.org/discuss/read/d6308614 . The page for extension pack 116, which this proposal was added to, is really empty. What’s the status of it now? From what I can read in volume 1 in the specification, it should be available in SP3 as it is included in an extension pack. When will SP3 be released? I’m guessing the EP shouldn’t be used yet as most field tags in the current document are TBD.
There was also a request for thoughts about throttling in November 2009 (http://www.fixprotocol.org/documents/4833/throttling%20request.doc). Was there any conclusions drawn from these comments? Is it possible to see them?
Thank you,
Jonas
I’m a thesis worker doing my work regarding flow control in (distributed) FIX/FAST systems and more specifically, evaluating how to regulate market data.
Naturally, I’m interested in the throttling proposal by FPL found in http://www.fixprotocol.org/discuss/read/d6308614 .
I’m not sure how applicable this EP will be to your research.
The Message Throttle EP isn’t really about Market Data. Rather, it is about throttling orders, quotes, etc. And it is more of a permission mechanism than a flow control mechanism. In other words, how fast an exchange, ATS, etc. is willing to accept messages from its members, traders, etc. And what action should be taken if these limits are exceeded. (E.g. queue the message, reject the message, or disconnect the session.)
I’m a thesis worker doing my work regarding flow control in (distributed) FIX/FAST systems and more specifically, evaluating how to regulate market data.
Naturally, I’m interested in the throttling proposal by FPL found in http://www.fixprotocol.org/discuss/read/d6308614 .
I’m not sure how applicable this EP will be to your research.
The Message Throttle EP isn’t really about Market Data. Rather, it is about throttling orders, quotes, etc. And it is more of a permission mechanism than a flow control mechanism. In other words, how fast an exchange, ATS, etc. is willing to accept messages from its members, traders, etc. And what action should be taken if these limits are exceeded. (E.g. queue the message, reject the message, or disconnect the session.)
Yes, I do realize this proposal is not specifically concerning market data. But this is one way to regulate market data indirectly (by regulating input to the exchange) and thus I’m still interested in the proposal.
To not overflow our customers, we’ve promised them to only broadcast a certain volume of market data per second, and throttling is one way to keep that limit.
/Jonas
Jonas,
limiting the market data amount to a certain type of user (e.g. traders in front of a GUI) makes a lot of sense but I would not throttle the input to achieve that but aggregate (net) the output for that. Bandwidth can still be expensive for remote users and 1Mbps can go a long way if you net the data every one or two seconds without reducing its value. During the netting interval you simply overwrite your internal buffers and flush them out at the end of the interval. You can use the same message layouts not netted and un-netted feeds.
Throttling is more about protection of a central system from rogue applications. You want to get in as much volume as your system can take without impacting other users and netting market data can make that output highly predictable to others who do not want such frequent price updates.
Regards,
Hanno.
Yes, I do realize this proposal is not specifically concerning market data. But this is one way to regulate market data indirectly (by regulating input to the exchange) and thus I’m still interested in the proposal.
To not overflow our customers, we’ve promised them to only broadcast a certain volume of market data per second, and throttling is one way to keep that limit.
/Jonas
Hello!
Thanks for your comments, both of you. First of all I want to say this is regarding derivative trading with lots of orderbooks, meaning even sending batched updates every x second of all orderbooks might be too much. This would more or less be equal to broadcasting scheduled snapshots (of whatever has changed since last) at a certain interval, if I understand it correctly.
The problem for us is that even customers that want ALL market data are closing in on their receive limits. Offering delayed market data (by sending aggregated updates) is a service that would be interesting, but it does not solve this problem.
/Jonas
Jonas,
limiting the market data amount to a certain type of user (e.g. traders in front of a GUI) makes a lot of sense but I would not throttle the input to achieve that but aggregate (net) the output for that. Bandwidth can still be expensive for remote users and 1Mbps can go a long way if you net the data every one or two seconds without reducing its value. During the netting interval you simply overwrite your internal buffers and flush them out at the end of the interval. You can use the same message layouts not netted and un-netted feeds.
Throttling is more about protection of a central system from rogue applications. You want to get in as much volume as your system can take without impacting other users and netting market data can make that output highly predictable to others who do not want such frequent price updates.
Regards,
Hanno.Yes, I do realize this proposal is not specifically concerning market data. But this is one way to regulate market data indirectly (by regulating input to the exchange) and thus I’m still interested in the proposal.
To not overflow our customers, we’ve promised them to only broadcast a certain volume of market data per second, and throttling is one way to keep that limit.
/Jonas
Aggregating (netting) does not mean batching, it means loss of information without causing a loss of business relevant information for the given use case. For example, a trader sitting in front of a GUI and watching prices, making decisions on what he sees, does not need to see all changes (flickering screen). It may be sufficient for him to get the latest bid and offer prices every second. The exchange system still generates new bids and offers at a much higher rate but the market data component overwrite its table entries for the various price levels, flushing it out in regular intervals. That makes bandwidth predictable but will only cover a subset of use cases for market data. Algo traders with software processing market data and making decisions based on the data will always want as much data as they can get and will not fall under these use cases.
Hello!
Thanks for your comments, both of you. First of all I want to say this is regarding derivative trading with lots of orderbooks, meaning even sending batched updates every x second of all orderbooks might be too much. This would more or less be equal to broadcasting scheduled snapshots (of whatever has changed since last) at a certain interval, if I understand it correctly.
The problem for us is that even customers that want ALL market data are closing in on their receive limits. Offering delayed market data (by sending aggregated updates) is a service that would be interesting, but it does not solve this problem.
/Jonas
Jonas,
limiting the market data amount to a certain type of user (e.g. traders in front of a GUI) makes a lot of sense but I would not throttle the input to achieve that but aggregate (net) the output for that. Bandwidth can still be expensive for remote users and 1Mbps can go a long way if you net the data every one or two seconds without reducing its value. During the netting interval you simply overwrite your internal buffers and flush them out at the end of the interval. You can use the same message layouts not netted and un-netted feeds.
Throttling is more about protection of a central system from rogue applications. You want to get in as much volume as your system can take without impacting other users and netting market data can make that output highly predictable to others who do not want such frequent price updates.
Regards,
Hanno.Yes, I do realize this proposal is not specifically concerning market data. But this is one way to regulate market data indirectly (by regulating input to the exchange) and thus I’m still interested in the proposal.
To not overflow our customers, we’ve promised them to only broadcast a certain volume of market data per second, and throttling is one way to keep that limit.
/Jonas
Algo traders with software processing market data and making decisions based on the data will always want as much data as they can get and will not fall under these use cases.
In our case this does apply the the high end algo traders. Even to the high end market data customers we have to give some kind of upper limit on message quantity that we will not exceed.
However; my original question was just to see the actual contents of extension pack 116. Was the proposal accepted in full or was there any changes?
There were changes along the way so I am not sure which version you are referring to. Please have a look at http://www.fixprotocol.org/documents/4992/FIX%20Protocol%20Gap%20Analysis%20-%20Message%20Throttle%20v%200.13_ASBUILT.doc. It has a history of changes inside the document.
Algo traders with software processing market data and making decisions based on the data will always want as much data as they can get and will not fall under these use cases.
In our case this does apply the the high end algo traders. Even to the high end market data customers we have to give some kind of upper limit on message quantity that we will not exceed.
However; my original question was just to see the actual contents of extension pack 116. Was the proposal accepted in full or was there any changes?
Thank you!
I have read v0.13 before (from the RFC thread here) but now I see the TBD’s have somehow magically disappeared, great news! 
Now I’ll just have to wait until 5.0 SP3 arrives eventually…
There were changes along the way so I am not sure which version you are referring to. Please have a look at http://www.fixprotocol.org/documents/4992/FIX%20Protocol%20Gap%20Analysis%20-%20Message%20Throttle%20v%200.13_ASBUILT.doc. It has a history of changes inside the document.
Algo traders with software processing market data and making decisions based on the data will always want as much data as they can get and will not fall under these use cases.
In our case this does apply the the high end algo traders. Even to the high end market data customers we have to give some kind of upper limit on message quantity that we will not exceed.
However; my original question was just to see the actual contents of extension pack 116. Was the proposal accepted in full or was there any changes?
Now I’ll just have to wait until 5.0 SP3 arrives eventually…
===> No, you do not have to wait. Once it is approved and tag numbers are assigned, the extension is official and can be used immediately. Please let me know why you think you have to wait until SP3.
Thanks,
Hanno.