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

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

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

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

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 todays 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
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
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 (ICNP04
  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
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
GIST/NSIS Operation an Overview
NSLP View
TCP connection
NTLP View
(GIST C-mode)
Network View
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?

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)
GIST-data (70bytes data)
70 bytes
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
12
Performance evaluation testbed
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

14
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
Performance GIST v.s. RSVP (1)

• RSVPs CPU consumption is fairly small in large
  number of sessions
• GISTs CPU consumption is larger than RSVP -
  still works with 60k session
• ? bottleneck likely due to the processing of GIST
  header

16
Performance GIST v.s. RSVP (2)

• GISTs 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
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
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-goett
  ingen.de/nsis
• Publications http//www.tmg.cs.uni-goettingen.de/
  publications

19
Thank you!

• Questions, comments appreciated