Transcript GIST - Columbia University

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)
Telematics group
University of Göttingen, Germany
Telematics group
University of Göttingen, Germany
Overview
• Background and motivation
• GIST/NSIS operation overview
• Evaluation
– Overhead
– Performance/scalability
– Extensibility
• Conclusion
Xiaoming Fu ([email protected])
2
Telematics group
University 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…
Firewall
B
Host A NAT
10.1.1.4
QoS
C New traffic class
Host D
• Not in harmony with the Internet architecture
• Require certain network control state configuration
– Network-layer (control) signaling protocol is needed
Xiaoming Fu ([email protected])
3
Telematics group
University 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
Xiaoming Fu ([email protected])
4
Telematics group
University 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)
Xiaoming Fu ([email protected])
5
Telematics group
University 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
Xiaoming Fu ([email protected])
6
Telematics group
University of Göttingen, Germany
GIST: the fundamental building block in NSIS
Two 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!
Xiaoming Fu ([email protected])
7
Telematics group
University 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
level
– NSLP do not care about transport at all
Signaling
Application -QoS
Signaling
Application - ANO
Signaling
Application - midcom
GIST State Maintenance
NTLP level
GIST Message Encapsulation
UDP
DCCP
SCTP
IP
Security
Protocols
(TLS, IPsec)
TCP
GIST
Focus of specification
is this
...which includes management of all of this
IP
Xiaoming Fu ([email protected])
8
Telematics group
University of Göttingen, Germany
GIST/NSIS Operation: an Overview
Need QoS!
NSLP
View
Need QoS!
NSLP
Layer
NSLP
Layer
Here it is!
Need QoS
NSLP
Layer
Here it is!
Here it is!
Are you my
next node?
(discovery)
Abstraction
NTLP
View
Network
View
NTLP
Layer
UDP
Transport
(GIST D-mode)
NTLP
Layer
NSIS router
Router
NSIS
without
Host A
NSIS
Xiaoming Fu ([email protected])
TCP connection
NSLP
Layer
NTLP
Layer
NTLP
Layer
NSIS router
NSIS
Host B
(GIST C-mode)
Router
without
NSIS
9
Telematics group
University 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?
Xiaoming Fu ([email protected])
10
Telematics group
University of Göttingen, Germany
Overhead analysis
104+
bytes
368+
bytes
GIST discovery requires a 3-way handshake,
368 bytes for message association
104+
setup with additional benefit of security andbytes
multiplexing
RSVP
70+ does not need message associate and relies on state refreshes
bytes
For application-specific state data delivery:
GIST data requires only 1-way, 70 bytes for each NSLP data delivery
70+ requires 2-way exchange, 104+ bytes for (QoS) signaling data delivery
RSVP
bytes
For many application scenarios, message associations can be maintained
half-permanent (e.g. hours to days): the 1-way 70 bytes overhead is tolerable
Xiaoming Fu ([email protected])
11
Telematics group
University of Göttingen, Germany
Performance evaluation: testbed
Background
Traffic generator
Background
Traffic generator
S1
D1
100Mbps
100mbps
S2
100mbps
R1
100Mbps
R2
1GMbps
R2
100Mbps
D2
100mbps
100Mbps
D3
S3
H1
Xiaoming Fu ([email protected])
S3
12
Telematics group
University of Göttingen, Germany
Performance: GIST e2e signaling latency
Avg. RTT (seconds)
7
6
5
4
3
2
1
60000
55000
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
1000
0
0
Number of sessions
•
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
Xiaoming Fu ([email protected])
13
Telematics group
University of Göttingen, Germany
Performance: how the implementation
segments contribute to overall processing
XOPP
XORP timer
Receiving external messages
53%
42%
8%
Receiving and distribute to FSM
Message parsing
Message composing and internal reading
Session data management (hash table)
4%
4%
17%
8%
NSLP level processing (“ping”)
Others
1%
6%
Xiaoming Fu ([email protected])
14
Telematics group
University of Göttingen, Germany
Performance: GIST v.s. RSVP (1)
GIST (D-m ode)
RSVP
60000
55000
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
1000
80
70
60
50
40
30
20
10
0
0
CPU consumption (%)
GIST (C-m ode)
Number of sessions
• 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
Xiaoming Fu ([email protected])
15
Telematics group
University of Göttingen, Germany
Performance: GIST v.s. RSVP (2)
RSVP
60000
55000
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
1000
160
140
120
100
80
60
40
20
0
0
Memory consumption (MB)
GIST (C-mode)
Num be r of s e s s ions
•
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)
Xiaoming Fu ([email protected])
16
Telematics group
University 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
Xiaoming Fu ([email protected])
17
Telematics group
University 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
Xiaoming Fu ([email protected])
18
Telematics group
University of Göttingen, Germany
Thank you!
Questions, comments appreciated
Xiaoming Fu ([email protected])
19