libvma
libvma copied to clipboard
Configurable message/packet number limits
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 [email protected]
on 30 Mar 2014 at 10:26
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 [email protected]
on 30 Mar 2014 at 10:28