Telematics group University of Göttingen, Germany Overhead and Performance Study of the General...

Telematics groupUniversity 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 Xiaoming Fu ([email protected])


Overview

• Background and motivation• GIST/NSIS operation overview• Evaluation

– Overhead– Performance/scalability– Extensibility

• Conclusion



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

10.1.1.4

NAT BHost A

New traffic class

Firewall

Host DC

QoS



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



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)



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



GIST: the fundamental building block in NSISTwo 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!



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

SecurityProtocols

(TLS, IPsec)

SignalingApplication - midcom

SignalingApplication -QoS

NS

LP

le

ve

lN

TL

P l

ev

el

IP

SignalingApplication - ANO

GISTGIST Message Encapsulation GIST State Maintenance

UDP TCPDCCP SCTP

IP

...which includes management of all of this

Focus of specification is this



TCP connection

GIST/NSIS Operation: an Overview

NSISHost A

NSISHost B

NSIS router

NetworkView

RouterwithoutNSIS

RouterwithoutNSIS

NSIS router

NTLPView

NTLPLayer

NTLPLayer

NTLPLayer

NTLPLayer

NSLPView

NSLPLayer

NSLPLayer

NSLPLayer

NSLPLayer

UDPTransport

(GIST D-mode)

Are you mynext node?(discovery)

Need QoS!

Here it is! Here it is!

Here it is!

Abstraction

Need QoS!Need QoS

(GIST C-mode)



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?



Overhead analysisGIST-query (112-144bytes)

GIST-response

(148-180bytes)

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 multiplexingRSVP 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 deliveryRSVP 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



S1

S2

S3

R1

100mbps

BackgroundTraffic generator

H1

R2

D1

D2

BackgroundTraffic generator

100mbps 100Mbps

100Mbps

1GMbps R2100Mbps

S3

100mbps

D3

100Mbps

Performance evaluation: testbed



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

0

1

2

3

4

5

6

7

0

10

00

50

00

10

00

0

15

00

0

20

00

0

25

00

0

30

00

0

35

00

0

40

00

0

45

00

0

50

00

0

55

00

0

60

00

0

Number of sessions

Av

g. R

TT

(s

ec

on

ds

)



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%



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

01020304050607080

0

10

00

50

00

10

00

0

15

00

0

20

00

0

25

00

0

30

00

0

35

00

0

40

00

0

45

00

0

50

00

0

55

00

0

60

00

0

Number of sessions

CP

U c

on

su

mp

tio

n (

%) GIST (C-mode) GIST (D-mode) RSVP



020406080

100120140160

0

10

00

50

00

10

00

0

15

00

0

20

00

0

25

00

0

30

00

0

35

00

0

40

00

0

45

00

0

50

00

0

55

00

0

60

00

0

Number of sessions

Mem

ory

co

nsu

mp

tio

n (

MB

)

GIST (C-mode) RSVP

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)



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



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



Thank you!

Questions, comments appreciated

Telematics group University of Göttingen, Germany Overhead and Performance Study of the General...

Documents

Transcript of Telematics group University of Göttingen, Germany Overhead and Performance Study of the General...