Telematics groupUniversity of Göttingen, Germany
Overhead and Performance Study of the General Internet Signaling Transport (GIST) Protocol
Xiaoming Fu (Uni Goettingen)
Henning Schulzrinne (Columbia Uni) Hannes Tschofenig (Siemens)
Christian Dickmann, Dieter Hogrefe (Uni Goettingen)
2 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Overview
• Background and motivation• GIST/NSIS operation overview• Evaluation
– Overhead– Performance/scalability– Extensibility
• Conclusion
3 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Background• Routers nowadays are expected to do more than IP routing and forwarding
– NAT, firewall, cache, …– Can also be QoS and other boxes – PHB, profile meters, AQM etc…
• Not in harmony with the Internet architecture• Require certain network control state configuration
– Network-layer (control) signaling protocol is needed
10.1.1.4
NAT BHost A
New traffic class
Firewall
Host DC
QoS
4 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Network Control Signaling Protocol Examples
• Path-decoupled (Client/Server)– COPS– MEGACO– DIAMETER– MIDCOM
• Path-coupled– Resource Reservation Protocol (RSVP)
• IETF proposed standard for QoS signaling (03/97)
– IETF NSIS (Next Steps in Signaling) • with QoS signaling as first application
5 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
RSVP review
• RFC 2205 • Signaling for Integrated Service QoS models (GS, CLS)
– Per-flow reservation– Multicast flow– Limited extensibility (objects and semantics specifically for QoS) – Refreshes: packet losses due to congestion, route changes etc– Not adapted to today’s needs: mobility, other signaling purposes
(midcom, diagnostics…)– No solid security framework and no support for AAA architecture
• RFC 2961: added hop-by-hop reliability and summary refreshes• Other extensions: aggregated reservation, reservation over
different networks (MPLS, 802.x)
6 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
NSIS Framework (RFC 3726)
• A two-layer split– Transport layer (NTLP or GIST): message transport– Signalling layer (NSLP): QoS NSLP, NATFW NSLP, etc.
• Contains the application intelligence
• Flexible/extendable multiple signalling application– Per flow QoS (IntServ)– Flow aggregate QoS (DiffServ)– Firewall and Network Address Translator (NAT)– And others
7 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
GIST: the fundamental building block in NSISTwo names for NSIS transport layer:• NTLP (the basic concept)• GIST (the protocol implementation): General Internet Signalling Transport• Based on the CASP (Cross-Layer Signaling Protocol) that we developed in
2002/03 (ICNP’04 paper)
• Key design choices believed to enhance RSVP:• Separation of signaling transport from application (two-layer split)• Flexible/extendable message transport (reuse TCP/SCTP/UDP/…)
• Reliability/ordering provisioning • Other common transport functions (congestion control, fragmentation, ..)
• Separation of discovery from signaling transport• Introduction of mobility/location-independent session identifier
• Also enables several key security properties
• Needs to justify/evaluate this design Main contribution of this paper!
8 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
GIST: an introduction• GIST responsible for
– Transport signalling message through network– Finding necessary network elements
• Abstraction of transport to NSLPs– NSLP do not care about transport at all
SecurityProtocols
(TLS, IPsec)
SignalingApplication - midcom
SignalingApplication -QoS
NS
LP
le
ve
lN
TL
P l
ev
el
IP
SignalingApplication - ANO
GISTGIST Message Encapsulation GIST State Maintenance
UDP TCPDCCP SCTP
IP
...which includes management of all of this
Focus of specification is this
9 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
TCP connection
GIST/NSIS Operation: an Overview
NSISHost A
NSISHost B
NSIS router
NetworkView
RouterwithoutNSIS
RouterwithoutNSIS
NSIS router
NTLPView
NTLPLayer
NTLPLayer
NTLPLayer
NTLPLayer
NSLPView
NSLPLayer
NSLPLayer
NSLPLayer
NSLPLayer
UDPTransport
(GIST D-mode)
Are you mynext node?(discovery)
Need QoS!
Here it is! Here it is!
Here it is!
Abstraction
Need QoS!Need QoS
(GIST C-mode)
10 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Evaluation• Overhead
– Will the overhead added by NSIS be too large?
• Performance/scalability– Can it be scalable for large number of sessions and nodes?
• Extensibility– Can it be easily extended to allow any new signaling applications?
• Others (beyond this paper):– Mobility: can it be ran in IP-based mobile networks?– Security: Can it be well protected without much performance
penalty?
11 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Overhead analysisGIST-query (112-144bytes)
GIST-response
(148-180bytes)
GIST-confirm(108bytes + data)
368+ bytes
GIST-data(70bytes + data)
RSVP-Path (52bytes)
RSVP-Resv
(72-144Bytes for IntServ)104+ bytes
RSVP-Path (52bytes)
RSVP-Resv
(72-144bytes for IntServ)104+ bytes
70+ bytes
70+ bytes
GIST-data(70bytes + data)
GIST discovery requires a 3-way handshake, 368 bytes for message association setup with additional benefit of security and multiplexingRSVP does not need message associate and relies on state refreshes
For application-specific state data delivery:GIST data requires only 1-way, 70 bytes for each NSLP data deliveryRSVP requires 2-way exchange, 104+ bytes for (QoS) signaling data delivery
For many application scenarios, message associations can be maintained half-permanent (e.g. hours to days): the 1-way 70 bytes overhead is tolerable
12 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
S1
S2
S3
R1
100mbps
BackgroundTraffic generator
H1
R2
D1
D2
BackgroundTraffic generator
100mbps 100Mbps
100Mbps
1GMbps R2100Mbps
S3
100mbps
D3
100Mbps
Performance evaluation: testbed
13 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Performance: GIST e2e signaling latency
• GIST scales well in terms of e2e signaling delay in large number of sessions– Fairly small (less than 20ms) under 55k sessions– Start to become worse when session number grows from more than 55k
• Most likely due to overloaded GIST CPU computation power
0
1
2
3
4
5
6
7
0
10
00
50
00
10
00
0
15
00
0
20
00
0
25
00
0
30
00
0
35
00
0
40
00
0
45
00
0
50
00
0
55
00
0
60
00
0
Number of sessions
Av
g. R
TT
(s
ec
on
ds
)
14 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Performance: how the implementation segments contribute to overall processing
XOPP 53%
XORP timer 42%
Receiving external messages 8%
Receiving and distribute to FSM 4%
Message parsing 4%
Message composing and internal reading 17%
Session data management (hash table) 8%
NSLP level processing (“ping”) 1%
Others 6%
15 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Performance: GIST v.s. RSVP (1)
• RSVP’s CPU consumption is fairly small in large number of sessions
• GIST’s CPU consumption is larger than RSVP - still works with 60k session bottleneck likely due to the processing of GIST header
01020304050607080
0
10
00
50
00
10
00
0
15
00
0
20
00
0
25
00
0
30
00
0
35
00
0
40
00
0
45
00
0
50
00
0
55
00
0
60
00
0
Number of sessions
CP
U c
on
su
mp
tio
n (
%) GIST (C-mode) GIST (D-mode) RSVP
16 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
020406080
100120140160
0
10
00
50
00
10
00
0
15
00
0
20
00
0
25
00
0
30
00
0
35
00
0
40
00
0
45
00
0
50
00
0
55
00
0
60
00
0
Number of sessions
Mem
ory
co
nsu
mp
tio
n (
MB
)
GIST (C-mode) RSVP
Performance: GIST v.s. RSVP (2)
• GIST’s memory consumption scales well in large number of sessions– Slightly worse than RSVP in serving more than 15k sessions
• Due to the additional message association state
– Slightly better than RSVP in serving less than 15k sessions• Due to our optimization in the code (e.g., session data management)
17 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Extensibility analysis• NSIS allows
– GIST to use of any types of discovery mechanism• By defining a new message routing method (MRM)
– Definition of any new NSLPs
• Support a large variety of transport protocols for GIST– SCTP and PR-SCTP– TCP– UDP (and even DCCP if available)
• In the implementation level:– The GIST daemon and GIST-API are developed with sufficient
modularity/independency on underlying platforms and NSLPs– Currently we support Linux, xBSD, and MacOSX: fairly easy to port
18 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Conclusion
• Next Steps in Signaling framework (NSIS) tries to address the modularity, extensibility, transport, and security issues in RSVP– Not only QoS signaling, but also generic signaling for any type of
middlebox configuration– Fundamental building block: GIST protocol
• GIST adds discovery component (thus imposing overhead), but for data transport phase, overhead is comparable as RSVP– the complexity worth the added security, extensibility, and modularity. – The main processing time comes from implementation choice (e.g.,XORP)
• GIST performance is comparable with RSVP, with good scalability in e2e signaling latency
• GIST/NSIS implementation: http://user.cs.uni-goettingen.de/~nsis• Publications: http://www.tmg.cs.uni-goettingen.de/publications
19 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Thank you!
Questions, comments appreciated
Top Related