This article is courtesy of Nadeem Zahid, director of Product Management and Marketing at cPacket Networks
When it comes to financial services and market trading, time really is the money – especially for sectors like high frequency trading, banking, and insurance. The real-time nature of financial services means that any issues with underlying systems and infrastructure will likely impact transactions, which in turn directly impacts revenue. That’s why many FinServ firms have been at the forefront of adopting the latest and fastest technology, in particular ultra-low latency 100Gbps network connections. Speed, bandwidth and latency are critical in FinServ: the high volume of data, the fact that it can be subject to frequent bursts, and the fact that fractions of a second can mean the difference between profit and loss all combine to put tremendous strain and focus on underlying network operations. Overall, those mission-critical networks represent some of the most demanding IT environments in the world.
FinServ Network Challenges
While networks worldwide face common issues, such as packet loss, jitter and latency, security, etc., the criticality of the infrastructure, and its operational extremes amplify the need for FinSev companies to keep a close eye on network operations. Those organizations face three unique challenges in particular:
- Increased Volume and Velocity of Data – Trading volumes handled by worldwide exchanges continue to grow, forcing exchanges, data providers and FinServ firms to continually expand network capacity. Moreover, the velocity of this data is increasing, as firms move to 40Gbps and now 100Gbps environments. Finally, market and trading data is often event-driven, making traffic subject to extreme fluctuations in traffic levels. This sets up the potential for spikes and bursts that exceed network capacity, causing critical trading data to be dropped. When traffic in a UDP stream is dropped, that data is permanently lost, directly impacting customer trading activity. Additionally, these spikes can occur across very short spans, resulting in microbursts that can be difficult to detect. A single microburst can cause a capacity overrun, which can result in missed trade order placements, missed trade confirmations, and gaps in market data feeds that result in financial losses when pursuing hedging and other trading strategies. Yet 100Gbps connections are expensive and can take time to provision, so firms are trapped in a catch-22: they can’t afford to add too much excess capacity to accommodate bursts, but similarly can’t afford to drop packets.
- Real Time Operations – Most market data feeds operate in real time, with decisions made based on the assumption that the data is absolutely current. Tick-to-trade latency (i.e., the time between a market movement and an executed trade) can directly determine success, meaning that significant latency or jitter can result in loss of revenue for the trading desk. Outside the trading desk, market data providers operate under the strictest of service level agreements (SLAs), meaning minute deviation can result in severe penalties. Market feeds are made up of UDP multicast streams that deliver real-time market data from the exchanges to brokerage houses, in-between exchanges, and to large algorithmic traders. Each level of customer relies on SLAs to ensure their data feed is correct and complete. This multi-tiered SLA structure causes any network fault to become a game of finger-pointing to determine the source of the problem. While a gap or out-of-sequence error in the feed could come from the data seller, it could also come from the operator’s own production network infrastructure or could be a false positive that comes from within their monitoring network.
- Security and Compliance – Regulatory compliance and oversight are more common in financial services than virtually any other industry. Similarly, the vast amount of money and valuable data that changes hands every minute makes these firms highly lucrative targets for cybercriminals. Both of these issues up the ante in terms of maintaining network integrity, and both make visibility into network operations critical. Any gaps in visibility create space for systems to drift out of compliance or for bad actors to operate.
Yet monitoring and visibility for ultra-low latency 100Gbps is notoriously difficult today; only the very latest monitoring equipment can handle the speed of 100G, as well as deliver the millisecond resolution required to truly understand what’s going on.
How To Monitor Low-Latency 100Gbps
So, what should FinServ organizations be looking for to improve 100Gbps network visibility for real-time monitoring? Two capabilities are key:
High-Resolution Stream Analysis – since microbursts can be a frequent and damaging occurrence that are completely missed by low-resolution analysis, companies need the ability to monitor a broad range of high-speed data streams (up to 100Gbps) with resolution as fine-grained as one millisecond. By default, this means monitoring must happen in hardware at the wirespeed (software solutions need not apply), and not rely on proxies, such as buffer utilization, or sampled flow-based analysis. Also, systems that perform software-based analysis are prone to their own spikes and bursts, which can cause false-positives within the monitoring infrastructure that aren’t in the production network.
Importantly, this level of resolution in network monitoring provides predictive indicators of network operation, allowing for proactive management before trading is impacted. Essentially, if network operators can detect bursts through early identification, network traffic can be reallocated to links with more capacity, giving them the ability to rebalance traffic in anticipation of network congestion and increased traffic. In fact, solutions that incorporate programmatic APIs in addition to high resolution can provide direct access to data for forecasting, visualization, and analytics.
Nanosecond Timestamping – As discussed, network latency can directly impact the timing of trading activity. To reduce any potential delays in network traffic, operators use precision timestamps at the wire to precisely sync activity across the network. The greater the accuracy and granularity of this timestamp, the better the ability to “stamp” out latency. Yet any queuing or traffic buffering can contaminate this timestamping. In fact, nanosecond resolution can even be subject to issues as prosaic as vibration or heat, making it extremely difficult to achieve. Again, only the latest solutions deliver.
The Importance of Network Monitoring
Network monitoring is crucial for performance, operations and security. However, the rapid expansion of financial networks, along with their high traffic speed and volume, can make it difficult to accomplish. Using network visibility solutions that aren’t designed from the ground up to handle ultra-low latency or 100Gbps speeds can end up masking issues, hiding performance degradation and resulting in revenue losses and potential compliance or security exposure. Lossless monitoring and the real-time observability of metrics, processing and routing that goes along with it is technically challenging for network packets that go through the monitoring fabric every 6.7 nanoseconds.
Keep in mind, not every part of a FinServ organization needs to move to the highest data rates. Specific devices and tools might remain at lower speeds because the vendors have not upgraded their products. Moreover, complex enterprise networks are rarely upgraded in their entirety all at once. In these instances, network packet brokers – a key part of an overall monitoring infrastructure – can also serve as a bridge between faster and slower data rates, matching the ingestion limitations of devices and tools to extend their useful life.
Yet for many FinServ networks, the most critical portions of their operation have already made the leap to 100Gbps. Comprehensive visibility and monitoring is not an option, it’s a requirement. Fortunately, the latest solutions can be up to the task…but only if you know what to look for.
Contributors
