Download Time Synchronization in Financial Services Industry – A deep dive

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Airborne Networking wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Lag wikipedia , lookup

Peering wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Peer-to-peer wikipedia , lookup

Juniper Networks wikipedia , lookup

Transcript
San Jose, USA,
June. 2016
Time Synchronization in Financial
Services Industry – A deep dive
Kamatchi Gopalakrishnan
Distinguished Engineer
[email protected]
1
Copyright © 2016 Juniper Networks, Inc.
Agenda
2
1
Time-sync requirements in Financial Services Industry
2
Precision Timing in Financial Networks
3
Precision Timing - Challenges and Architecture solution
4
Summary
Copyright © 2016 Juniper Networks, Inc.
1
3
Time-sync requirements in Financial Services Industry
Copyright © 2016 Juniper Networks, Inc.
Time Legality
•  How do you prove that something happened before (or
after) a certain time?
•  How do you prove that a new billing cycle has started?
•  How do you correlate events across a large/global
network?
– Hacking attacks
4
Copyright © 2016 Juniper Networks, Inc.
ESMA and Regulatory Requirements
•  MiFID-2 and MiFIR
•  RTS and ITS
Ø  Fairer, safer and more efficient markets
Ø  Greater transparency
Ø  Stronger investor protection
•  Clock/Time synchronization
Ø  RTS 25 – Regulatory Technical and implementing standards – annex 1
(September 2015 | ESMA/2015/1464)
Ø  Definition of business clocks and time accuracy requirements for
business clocks
5
Copyright © 2016 Juniper Networks, Inc.
Adopted regulatory synchronization requirements
•  Reference Time - UTC
•  Compliance with maximum divergence requirements
•  Level of accuracy for operator of trading venues
6
Gateway-to-Gateway
latency-meoftrading
system
Maximumdivergence
fromUTC
Granularityofthe
-mestamp
>Millisecond
1millisecond
1millisecondorbe0er
=<1millisecond
100microseconds
1microsecondorbe0er
Copyright © 2016 Juniper Networks, Inc.
Regulatory synchronization requirements …
•  Level of accuracy for member or participants of a trading venue
7
Typeoftradingac-vity
Maximumdivergence
fromUTC
Granularityof
-mestamp
Highfrequency
algorithmictrading
100microseconds
1microsecondorbe0er
Voicetrading
1second
1secondorbe0er
Requestforquote
systems
1second
1secondorbe0er
Nego@atedtransac@on
1second
1secondorbe0er
Anyothertrading
1millisecond
1millisecondorbe0er
Copyright © 2016 Juniper Networks, Inc.
2
8
Precision timing in Financial Services Industry
Copyright © 2016 Juniper Networks, Inc.
Case1 - Accuracy in Hi-FREQ algorithmic trading
TradeExecu-on
Servers
MarketData
Crea-onServers
TradeExecu-on MarketDataCrea-on
T3
T2
Timestamp
Timestamp
T1
T3
MarketFeed
Timestamp
Algorithmic
TradingServers
9
MarketFeed
Generator
Servers
T2
Market
Data
MarketFeed
Timestamp
2
3
4
5
6
7
1
WithNTPprecision,oQenT3
<T2<T1–ie,marketdatais
sentbeforeitiscreatedand
Themarketdatacrea@on
Themarketfeedreachesthe
Thetradeexecu@ondatais
Themarketfeedgenerator
Whenatradeexecutes,a
evenbeforethetradehas
Themarketdataissenttothe
serversgeneratea@mestamp
customers’algorithmicservers
senttothemarketdata
servers@mestampthefeed
@mestampisgeneratedbythe
beense0led!Algorithmsare
feedgeneratorservers
whennewmarketdatais
withthethree@mestamps
crea@onservers
whichtheysendout
tradeexecu@onserver
confusedleadingtolost
created
embedded
businessandangrycustomers
fortheexchange
WithPTP,exchangescanachievebeLer
precision(1usorless)thatwillletthem
fixthisproblem
T1
TradeData
AlgorithmicTrading
Algorithmic
Servers
TradingServers
Copyright © 2016 Juniper Networks, Inc.
Case 2: END-To-END Latency analysis
§  In HFT, latency is king
Ø  Race to “zero-latency”
Ø  Extensive investment in shaving off
nanoseconds
Marketdatafeed
BGP/OSPF
IPMul-cast
§  Different latency components
Ø  App-to-app latency across different cores in
the same server, across different servers
Ø  App-to-NIC, NIC-to-switch, switch-to-router
latency
HFTAlgorithmicTradingServers
10
Copyright © 2016 Juniper Networks, Inc.
Case 3: Logging for regulatory reasons
CustomerTrade
Requests
Marketdatafeed
BGP/OSPF
IPMul-cast
T1
T2
A
CustomerX
T3
B
BuyIBM@250
CustomerY
FillIBM@250
14
2
3
BuyrequestarrivesfromCustomerXforIBMop@onsat
BuyrequestarrivesfromCustomerYforIBMop@onsat
WithNTPprecision,itmightbethatT3<T1<T2,sothis
Tradeisexecuted(“filled”)byserverAat@meT2–log
serverA–@mestampedwithT1,recordsenttothelogging
serverC–@mestampedwithT3,recordsenttothelogging
ishowtheloglookslikewhenreadaQerthefact:
recordsenttologgingserver
server
server
BuyIBM@251
C
HFTAlgorithmic
LoggingServer
Raisesregulatoryconcernsaroundfairtrading
TradingServers
Precise-mingprovidedby1588toachieveaccuracyinloggingopera-onstoalleviate
regulatoryproblems
11
Copyright © 2016 Juniper Networks, Inc.
Case 4: Timing service provided by exchanges
§  Exchanges sell proximity services to
buy-side and sell-side customers –
Co-location
§  Customers need to derive an
accurate clock for Algo. engines
§  Exchanges deploy IRIG-B or GPS
services in every rack
Ø  Expensive
HFTAlgorithmicTradingServers
Customer1
Customer2
Ø  Often requires separate clock
distribution network
CustomerN
ExchangeCo-loca-onEnvironment
12
Copyright © 2016 Juniper Networks, Inc.
3
13
Precision Timing - Challenges and Architecture solution
Copyright © 2016 Juniper Networks, Inc.
Challenges in Network based Precision Timing
•  Challenge 1 - Packet Delay Variation
•  Challenge 2 - Scale : Number of PTP clients support
•  Challenge 3 - Number of hops between Grand Master and PTP
clients
•  Challenge 4 - PTP profile to be used – IEEE1588 default profile or
something else?
•  Challenge 5 - Precision Performance Monitoring
•  Challenge 6 - Vendor selection criteria
14
Copyright © 2016 Juniper Networks, Inc.
Network PDV
NoFloorShiQ
FloorShiQ
15
Copyright © 2016 Juniper Networks, Inc.
Solution for Network PDV and Node PDV
Ø Network PDV
§  Full path support
§  Use TC or BC clocks every hop between GM and Slave/Client nodes
§  Limit the number of hops based on the individual node performance
Ø  Node PDV
§  Validate the Node performance and ensure that hardware based (PHY or
MAC) time-stamping is supported
§  A simple PDV measurement with Data/Load traffic competing with PTP
traffic – a good case to validate
16
Copyright © 2016 Juniper Networks, Inc.
Challenge 2: PTP clients scaling
EXCHANGE
•  There can be 10 or 100 thousands
of servers in the financial trading
network.
•  No vendor GM can support 100
thousands PTP clients
•  Network design shall make use of
Boundary clocks hierarchically to
serve group of servers (PTP clients)
• 
EXCHANGE
HFTALGORITHMIC
TRADINGSERVERS
MARKETDATAFEED
ComputeCluster
Interconnect
BACKENDCOMPUTE
CLUSTER
17
CUSTOMERS
MONITORING
APPLICATIONS
Copyright © 2016 Juniper Networks, Inc.
Challenge 3 – Synchronization Network Hops
•  The length of synchronization chain from GM to end slave (Servers
with PTP clients) is key to achieve less than time accuracy.
•  Every node (BC or TC) introduce some time offset from its upstream
master termed as Time Error (TE).
§  Time error can be additive in a worst case scenario
§  Sum of time error < Target accuracy
Reference topology from Telecom world
18
Copyright © 2016 Juniper Networks, Inc.
Challenge 4 - Selection of Timing Profile
•  IEEE 1588 default profile
Ø  Generically written standard for PTP
Ø  All other profiles were derived from 1588
Ø  Supports BC, OC, TC clocks
Ø  Supports PTP over IPv4, IPv6 or L2 (Ethernet) transports
Ø  Unicast/Multicast packet exchanges allowed
•  IETF Enterprise profile
Ø  Mainly focuses on Enterprise/Datacenter applications
Ø  Supports BC, OC, TC clocks and No Peer-to-Peer timing
Ø  Supports PTP over IPv4 and IPv6 only.
Ø  Sync and Announce messages – Multicast, Delay-request and response
– Multicast or Unicast
19
Copyright © 2016 Juniper Networks, Inc.
Challenge 5 – PTP performance monitoring
Ø  Monitoring timing accuracy at 10s of thousands of
servers – Really challenging!!!
Ø  SNMP traps/alarms can be generated and monitored for:
§  System state change – Locked to a source, lost lock to
source, Acquiring to a source
§  BMCA changes including new source/master selection.
§  Clock qualification and signal failure condition
Ø  1PPS measurement?
20
Copyright © 2016 Juniper Networks, Inc.
Challenge 6: Vendor Selection Criteria
•  Node/Product selection criteria
Ø  Oscillator used
Ø  High resolution PHY/MAC time-stamping or similar support
Ø  Full control to change attributes and packet rates
Ø  How Smart – The servo algorithm?
Ø  PTP clients scale
Ø  Provision to performance monitoring support
• 
Breadth of solution – not just timing, and how good it is?
Ø  Spectrum of products with “End to End” solution
21
Copyright © 2016 Juniper Networks, Inc.
5
22
Summary
Copyright © 2016 Juniper Networks, Inc.
Summary
•  Three “important” attributes of FSI – Security, low latency
trading and time synchronization.
•  Failure of any attribute – may not be acceptable, can be
catastrophic.
•  Based on conditions of failure - lead to regulatory audits
and penalties
23
Copyright © 2016 Juniper Networks, Inc.
Thank you