Overhead and Performance Study of the General Internet

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 (fu@cs. uni-goettingen. de) 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 Qo. S and other boxes – PHB, profile meters, AQM etc… Firewall B Host A NAT 10. 1. 1. 4 Qo. S 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 (fu@cs. uni-goettingen. de) 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 Qo. S signaling (03/97) – IETF NSIS (Next Steps in Signaling) • with Qo. S signaling as first application Xiaoming Fu (fu@cs. uni-goettingen. de) 4

Telematics group University of Göttingen, Germany RSVP review • RFC 2205 • Signaling for Integrated Service Qo. S models (GS, CLS) – – – Per-flow reservation Multicast flow Limited extensibility (objects and semantics specifically for Qo. S) 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 (fu@cs. uni-goettingen. de) 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): Qo. S NSLP, NATFW NSLP, etc. • Contains the application intelligence • Flexible/extendable multiple signalling application – – Per flow Qo. S (Int. Serv) Flow aggregate Qo. S (Diff. Serv) Firewall and Network Address Translator (NAT) And others Xiaoming Fu (fu@cs. uni-goettingen. de) 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 (fu@cs. uni-goettingen. de) 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 do not care about transport at all Xiaoming Fu (fu@cs. uni-goettingen. de) 8

Telematics group University of Göttingen, Germany GIST/NSIS Operation: an Overview Need Qo. S! NSLP View Need Qo. S! NSLP Layer Here it is! Need Qo. S NSLP Layer 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 (fu@cs. uni-goettingen. de) TCP connection NSLP 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 (fu@cs. uni-goettingen. de) 10

Telematics group University of Göttingen, Germany Overhead analysis RSVP -P (52 by ath tes) GIST (112 - -query 144 b 104+ ytes) sv e bytes R rv) e P e S s V t n n S I R espo s) 368+ for r s T e t S GI byte 4 by 0 4 8 1 bytes 1 (72 (148 GIST RSVP (108 b -confirm -Path ytes ( 5 2 byte + dat s) association GIST discovery requires aa)3 -way handshake, 368 bytes for message 104+ setup with additional benefit of security andbytes multiplexing sv e R rv) e P S t V S GIS RSVP need associate and relies on state. Rrefreshes r In T-damessage o f 70+ does not s t a (70 byte B 4 4 s bytes + d ta) (72 -1 For application-specificastate data delivery: GIST data requires only 1 -way, 70 bytes for each NSLP data delivery GIST-d atexchange, a 70+ requires RSVP 104+ bytes for (Qo. S) signaling data delivery (70 by 2 -way tes + d ata) 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 (fu@cs. uni-goettingen. de) 11

Telematics group University of Göttingen, Germany Performance evaluation: testbed Xiaoming Fu (fu@cs. uni-goettingen. de) 12

Telematics group University of Göttingen, Germany Performance: GIST e 2 e signaling latency • GIST scales well in terms of e 2 e signaling delay in large number of sessions – Fairly small (less than 20 ms) under 55 k sessions – Start to become worse when session number grows from more than 55 k • Most likely due to overloaded GIST CPU computation power Xiaoming Fu (fu@cs. uni-goettingen. de) 13

Telematics group University of Göttingen, Germany Performance: how the implementation segments contribute to overall processing XOPP XORP timer Receiving external messages Receiving and distribute to FSM 53% 42% 8% 4% Message parsing Message composing and internal reading Session data management (hash table) NSLP level processing (“ping”) Others 4% 17% 8% 1% 6% Xiaoming Fu (fu@cs. uni-goettingen. de) 14

Telematics group University 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 60 k session bottleneck likely due to the processing of GIST header Xiaoming Fu (fu@cs. uni-goettingen. de) 15

Telematics group University of Göttingen, Germany 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 15 k sessions • Due to the additional message association state – Slightly better than RSVP in serving less than 15 k sessions • Due to our optimization in the code (e. g. , session data management) Xiaoming Fu (fu@cs. uni-goettingen. de) 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, x. BSD, and Mac. OSX: fairly easy to port Xiaoming Fu (fu@cs. uni-goettingen. de) 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 Qo. S 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 e 2 e signaling latency • GIST/NSIS implementation: http: //user. cs. uni-goettingen. de/~nsis • Publications: http: //www. tmg. cs. uni-goettingen. de/publications Xiaoming Fu (fu@cs. uni-goettingen. de) 18

Telematics group University of Göttingen, Germany Thank you! Questions, comments appreciated Xiaoming Fu (fu@cs. uni-goettingen. de) 19