[This message was posted by Steve Wilkinson of Cornerstone Technology Limited <ste...@cornerstonetechnology.com> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/f8544155 - PLEASE DO NOT REPLY BY MAIL.]
Fir what it's worth, I have to agree with Russ - the throttling concept feels very much like a Quality of Service scheme - I think we would do well to learn from other people's experience in solving similar QoS problems, or we destine ourselves to re-invent our own wheels all the time. Just my 2-cents worth. Steve. > Hi Ryan, > > Thanks for taking the time to reply. > > > I'm not sure I consider Throttling to be QoS. > > By definition, at least from the old ITU standards, QoS refers to: > > "A set of quality requirements on the collective behavior of one or more > objects" (in a network). > > Hanno's question made me wonder if he was talking about a dynamic > congestion relief mechanism (4=Warning) and if so, I was wondering which > existing works on QoS might be serving as the underpinnings for the > decisions being made in this proposal. > > I guess one of the problems that I've always seen when reading a number > of different FIX proposals, is that many of them seem to be devoid of > references/citations to prior art in the industry, much of which can be > very useful when creating new systems, since other people have already > spent significant amounts of time solving the problem at hand - or at > least one which is very similar... > > > This proposal was modeled on requirements stated by exchanges > > participating in the Global Exchanges and Markets Committee meetings, > > not by any QoS standard. > > I guess my interest wasn't in "which QoS standard does this implement" > but rather "which QoS works were referenced or consulted in its design." > Not to say that an existing QoS standard should be implemented in toto, > but rather to say that referencing existing works helps people > understand that the decisions related to the design of something are > grounded in successful implementations of the same thing from different > parts of the industry. > > That's a good thing, since it allows those of us who look at something > and try to implement it have more confidence that we're not going to be > looking at an errata in 3 months that says we have to make a bunch of > changes because something doesn't work right. > > I'm not saying this will happen with this particular proposal, but I'm > just pointing out that providing citations/references to existing bodies > of work helps us implementers understand that all the bases have been > covered and increases our degree of confidence that we can move forward > with something. > > > I see QoS as much more dynamic. Throttling rules are largely static. > > An exchange tells its members at the start of day how many orders per > > second they can send, and what consequences they can expect if they > > exceed those limits. They are just as much business rules as a > > technical strategy to avoid congestion. It is possible for these > > proposed Throttling messages to be sent intraday, but I haven't heard > > much exchange interest in doing so. It might be useful in emergency > > situations caused by reduced exchange capacity or an increase in > > market activity. But I certainly don't see an exchange sending one out > > every second to tell a member how many orders can be sent in that > > second. The idea of using QoS protocols for order flow sounds very > > interesting. However, extensions to FIX generally result from business > > requirements presented to FPL. Are there any exchanges that use, or > > plan on using, a QoS protocol? > > I guess this goes to my original concern - by definition, any exchange > that implements aspects of this proposal is implementing an application > level QoS protocol. If the only way to say this is not a QoS proposal is > to redefine QoS, that just seems like a bad way to go. [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
