angphie / libvma

Automatically exported from code.google.com/p/libvma
Other
0 stars 0 forks source link

Configurable message/packet number limits #13

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Background - after Knight Capital 
http://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stock_trading_disruption 
software related trading loss of $400+ million incured in minutes a lot of 
people have concerns about out of control trading algorithms. Even ~500 packet 
a second sent by out of control algorithm could create losses in tens of 
millions before human operator would even notice.

Of course libvma is by no means proper place to put real risk management and 
it'd be just one of the measures / lines of defence between trading algorithm 
and the exchange. Idea is to limit number of packets sent, it's the most 
damaging scenario - infinite loop in application sending orders. Of course the 
application layer would do all possible to prevent it but any additional layer 
would help.

Other network layers can provide some protection features (through QoS) but 
switches and OFED are MB/s oriented not packet/s oriented typically. Linux 
kernel has "tc" (traffic control) but I'm sure it'd incur very much latency and 
VMA can't be used. 

From technical perspective I see it as a counter(s) per application / remote 
destination configured in VMA conf . Once certain threshold value exceeded 
socket needs to be closed.

1. total number of packets (application would typically write entire trading 
order at once so number of socket write calls is okay) since some point (socket 
open or midnight local time) allowed, once limit exceeded please close the 
socket.
2. even better would be a limit on messages per unit of time, this value could 
be computed for example as exponential moving average (similar to Linux load 
average) per application and network destination.
3. this could impact latency somewhat but we could count a certain pattern in 
outgoing application flow i.e. "8=FIX.4.2" and count these instead of number of 
socket writes

Features 2, 3 are great to have but at least 1 would be of great help.
This patch could be in long term a marketing advantage of Mellanox.

Best
Denis

Original issue reported on code.google.com by denis.iv...@gmail.com on 30 Mar 2014 at 10:26

GoogleCodeExporter commented 9 years ago
Application do not have to have any control of this throttling mechanism.

It should be relatively easy to test with "iperf" or other tool which is 
capable of generating a bit of traffic.

Original comment by denis.iv...@gmail.com on 30 Mar 2014 at 10:28