1 / 19

Overhead and Performance Study of the General Internet Signaling Transport (GIST) Protocol

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). Overview. Background and motivation

marny-cook
Download Presentation

Overhead and Performance Study of the General Internet Signaling Transport (GIST) Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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. Overview • Background and motivation • GIST/NSIS operation overview • Evaluation • Overhead • Performance/scalability • Extensibility • Conclusion Xiaoming Fu (fu@cs.uni-goettingen.de)

  3. 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 NAT Host A 10.1.1.4 Host D New traffic class C QoS • 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)

  4. 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 (fu@cs.uni-goettingen.de)

  5. 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 (fu@cs.uni-goettingen.de)

  6. 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 (fu@cs.uni-goettingen.de)

  7. 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)

  8. 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)

  9. GIST/NSIS Operation: an Overview NSIS router NSIS router Need QoS! Need QoS! Need QoS NSLP Layer NSLP Layer NSLP Layer NSLP Layer Here it is! Here it is! Here it is! Are you my next node? (discovery) Abstraction UDP Transport (GIST D-mode) NTLP Layer NTLP Layer NTLP Layer NTLP Layer NSIS Host B NSIS Host A Router without NSIS Router without NSIS NSLP View TCP connection NTLP View (GIST C-mode) Network View Xiaoming Fu (fu@cs.uni-goettingen.de)

  10. 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)

  11. Overhead analysis RSVP-Path (52bytes) GIST-query (112-144bytes) 104+ bytes RSVP-Resv (72-144bytes for IntServ) GIST-response (148-180bytes) 368+ bytes GIST-confirm (108bytes + data) RSVP-Path (52bytes) 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 104+ bytes RSVP-Resv (72-144Bytes for IntServ) 70+ bytes GIST-data (70bytes + data) 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 GIST-data (70bytes + data) 70+ bytes Xiaoming Fu (fu@cs.uni-goettingen.de)

  12. Performance evaluation: testbed Xiaoming Fu (fu@cs.uni-goettingen.de)

  13. 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 Xiaoming Fu (fu@cs.uni-goettingen.de)

  14. Performance: how the implementation segments contribute to overall processing Xiaoming Fu (fu@cs.uni-goettingen.de)

  15. 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 Xiaoming Fu (fu@cs.uni-goettingen.de)

  16. 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) Xiaoming Fu (fu@cs.uni-goettingen.de)

  17. 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 (fu@cs.uni-goettingen.de)

  18. 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 (fu@cs.uni-goettingen.de)

  19. Thank you! Questions, comments appreciated Xiaoming Fu (fu@cs.uni-goettingen.de)

More Related