Telematics group University 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 Telematics group University of Göttingen, Germany Xiaoming Fu Overview Background and motivation GIST/NSIS operation overview Evaluation –Overhead –Performance/scalability –Extensibility Conclusion

3 Telematics group University of Göttingen, Germany Xiaoming Fu 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 NAT B Host A New traffic class Firewall Host D C QoS

4 Telematics group University of Göttingen, Germany Xiaoming Fu 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 Telematics group University of Göttingen, Germany Xiaoming Fu 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 Telematics group University of Göttingen, Germany Xiaoming Fu 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 Telematics group University of Göttingen, Germany Xiaoming Fu GIST: the fundamental building block in NSIS Two names for NSIS transport layer: NTLP (the basic concept) GIST (the protocol implementation): G eneral I nternet S ignalling T ransport 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 Telematics group University of Göttingen, Germany Xiaoming Fu 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

9 Telematics group University of Göttingen, Germany Xiaoming Fu TCP connection GIST/NSIS Operation: an Overview NSIS Host A NSIS Host B NSIS router Network View Router without NSIS Router without NSIS NSIS router NTLP View NTLP Layer NTLP Layer NTLP Layer NTLP Layer NSLP View NSLP Layer NSLP Layer NSLP Layer NSLP Layer UDP Transport (GIST D-mode) Are you my next node? (discovery) Need QoS! Here it is! Abstraction Need QoS! Need QoS (GIST C-mode)

10 Telematics group University of Göttingen, Germany Xiaoming Fu 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 Telematics group University of Göttingen, Germany Xiaoming Fu Overhead analysis GIST-query ( bytes) GIST-response ( bytes) 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 multiplexing RSVP 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 delivery RSVP 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 Telematics group University of Göttingen, Germany Xiaoming Fu Performance evaluation: testbed

13 Telematics group University of Göttingen, Germany Xiaoming Fu 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

14 Telematics group University of Göttingen, Germany Xiaoming Fu Performance: how the implementation segments contribute to overall processing XOPP53% XORP timer42% Receiving external messages8% Receiving and distribute to FSM4% Message parsing4% Message composing and internal reading17% Session data management (hash table)8% NSLP level processing (“ping”)1% Others6%

15 Telematics group University of Göttingen, Germany Xiaoming Fu 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

16 Telematics group University of Göttingen, Germany Xiaoming Fu 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 Telematics group University of Göttingen, Germany Xiaoming Fu 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 Telematics group University of Göttingen, Germany Xiaoming Fu 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: Publications:

19 Telematics group University of Göttingen, Germany Xiaoming Fu Thank you! Questions, comments appreciated