Signaling Protocol

1
Signaling Protocol

• Communication setup, tear-down and control
• Basic call service building blocks for
  supplementary services
• Conventional two party, homogeneous devices
• ICEBERG communication model
• multi-endpoint invitation-based communication
• richer primitives add/remove an endpt during a
  session
• conference call, service handoff first class
  service trivial to implement services that
  require endpoint changes.
• Other IT signaling protocols SIP, H.323

2
Problems with SIP
CA1
CA2
CA5
Alice
Bob
Carol
Dale
Carol
Dale

• no consideration of session dynamics membership,
  component failure
• bridged conference centralized component to
  maintain states -- single point of failure

3
Problems with H.323

• Centralized approach for conferencing
• Limited fault tolerance measure
• process-pair style
• cannot capture new state during fault recovery
• Complex

4
Lessons Learned

• Correctness and robustness
• need to maintain up-to-date membership and
  session state (call parties, device status, data
  path info) in the face of transient component
  failures, network partitions, and any exceptional
  conditions.
• distributed approach rather than centralized
• need a session maintenance protocol

5
ICEBERG Signaling ProtocolSession Maintenance
Protocol

• Maintain membership and session state as soft
  state in a distributed fashion through group
  communication
• Soft state expired unless refreshed, protocol
  action upon new state or timeout, error recovery
  same as normal operation

6
Signaling Protocol Session Membership

• Session membership
• membership CAs
• IP multicasts group service an overkill for
  small group communication
• per group state in routers, IP addr scarcity,
  deployment issues access control, accountability
• Solution run an application-level group
  membership protocol among participating IAPs

7
Signaling Protocol Capture the Complete Session
State
Call Agent
Call Agent
Session state
Session state
Group Comm Channel
iPOP
iPOP
IAP
IAP
Call Agent
Session state
IAP
iPOP
iPOP HB
8
Signaling Protocol Fault Tolerance
Call Agent
Call Agent
Session state
Session state
Group Comm Channel
APC
APC
iPOP
iPOP
IAP
IAP
IAP
APC
iPOP
iPOP HB
9
Signaling Protocol Fault Tolerance
Call Agent
Call Agent
Session state
Session state
Group Comm Channel
APC
APC
iPOP
iPOP
IAP
IAP
IAP
10
Signaling Protocol Fault Tolerance
Call Agent
Call Agent
Session state
Session state
Group Comm Channel
APC
APC
iPOP
iPOP
IAP
IAP
IAP
APC
11
Session Establishment Protocol

• Invite a Call Agent to participate a session
• Also a soft state protocol for robustness
• IAP maintains the call state machine, sends
  stateful, keep-alive heartbeat to the iPOP
• Call Agents advance call state machines on IAPs
  through periodic install-state message until
  receiving new heartbeat with the new state
• Soft state inter-iPOP communication

12
Soft State Period Selection and Bandwidth
Scalability

• Soft state period selection call setup latency,
  fault recovery time vs bandwidth overhead
• An optimization problem minimize bandwidth
  overhead, subject to the following constraints
• expected call setup latency (1.5 second)
• standard deviation (0.5 second)
• fault recovery time (1, 4 seconds for local and
  wide area)
• parameters 2 wide-area loss rate, 0.2
  local-area loss rate, 2ms local-area propagation
  delay, 100 ms wide-area delay
• local 1 sec, 800bps wide 3 sec, 233 bps for
  64kbps data stream, local-area control traffic 1
  

13
Processing Scalability

• Compare our single cluster system against a class
  4 switch which is a local (end) office 250
  calls/second
• Our current prototype yields 10 calls/second on a
  PC due to inefficient RMI implementation (10s
  ms), 25 PCs a class 4 switch

14
Comparison with SIP

• Compare in four aspects
• architecture
• state maintenance
• failure model
• service creation model

15
Comparison with SIPArchitecture

• ICEBERG
• client-cluster-client during session
  establishment phase
• peer-to-peer, group communication during session
  maintenance phase among CAs

• SIP
• client server, pair-wise communication

16
Comparison with SIPState Maintenance

• ICEBERG
• per client session state maintained on client
  (IAP) through periodic heartbeat
• complete session state as soft-state on CA,
  collected through announce-listen of CA

• SIP
• per client session state on client and server
• no session maintenance protocol after session
  initiation to capture the complete, session state
  which is highly dynamic.

17
Comparing with SIPFailure Model

• ICEBERG
• CA failure recovered by IAP keep-alive heartbeat
• iPOP failure IAP choose new iPOP
• IAP failure leads to communication failure for
  that endpoint

• SIP
• server failure (without server being able to send
  5xx responses) or being network partitioned
  causes client to relocate a new server, and retry
  from the beginning of the transaction
• no mechanism for recovering state from failed
  server

18
Comparing with SIPService Creation Model

• ICEBERG
• basic service multi-endpoint communication
• Callee plays main role in preference
  specification, while caller can only provide
  their status and wishes
• explicit generic, high level state machine

• SIP
• basic service two-party communication
• Caller and callee both play a role in preference
  specification

19
Comparing with SIPService Creation Model, Cont.

• Three ways of service creation
• preference specification
• state machine insertion
• new services through encapsulated app behind IAP
• Well-defined system interface (parameters,
  primitives)

• Two ways of service creation
• CPL (implicit state machine - error-prone)
• CGI

20
Backup slides after this one
21
Novel Services Enabled by ICEBERG

• arbitrary redirection services
• any-endpoint to any-endpoint communication
• chat-room with imode service
• pay-per-view service for any service

22
Related Work

23
Current Status

• First release for small scale, single domain
  deployment, service creation model not
  incorporated
• http//iceberg.cs.berkeley.edu/release/
• Second release for wide-area and
  cross-administrative domain deployment including
  the service creation model by the end of the
  summer

24
Soft and Hard State

• Soft State
• expire unless refreshed, protocol action upon new
  state and timeout
• loss of state will not stop the system -- robust
• eventual consistency
• error recovery built into normal operation
  --simple, but longer latency, and no diagnosis

• Hard State
• explicit state setup once only (bandwidth and
  processing efficiency)
• explicit error detection and recovery
  synchronously at involved components -- complex
  but immediate
• better consistency guarantees

25
Period Selection

• Soft State Period dominates fault recovery time,
  affects bandwidth overhead
• cannot trade latency for bandwidth scalability
• Problem what period values to select to fulfill
  the call setup latency, fault recovery latency
  requirements and minimize the bandwidth overhead?
  -- an optimization problem

26
Select PeriodProblem Formulation

• Call setup latency receiving 8 local-area and 4
  wide-area msgs in sequence msg processing time
• Receive a local-area msg f (local-area period,
  local-area loss-rate, local-area propagation
  delay)
• The optimization problem
• find local-area and wide-area period that
  minimize bandwidth overhead, subject to the
  following constraints
• E(call setup latency) lt1.5 second
• Standard deviation (call setup latency) lt 0.5
  second
• local-area fault recovery time lt1 s wide lt 4 s
• with parameters 2 wide-area loss rate, 0.2
  local-area loss rate, 2ms local-area propagation
  delay, 100 ms wide-area delay

27
Results Period f (processing)

• fault recovery time constraints dominate the
  effects on period
• local-area period 1s
• 800 bps overhead
• wide-area period 3s
• 233 bps overhead
• for 64kbps data stream, 1 of members

28
Signaling Protocol Group Membership Protocol

• Periodic membership exchange among members
• no bootstrapping needed every member knows at
  least one other member (invitation-based)
• receive superset or disjoint set immediate
  synchronization with the rest of the session
• run among the IAPs for Call Agent fault recovery
• time stamped ltIAP, CAgt list
• Convergence efficiency rather than bandwidth
  efficiency

29
References

• ICEBERG An Internet-core Network Architecture
  for Integrated Communications, Helen J. Wang et
  al, IEEE Personal Communications, August, 2000
• A Signaling System Using Lightweight Call
  Sessions, Helen J. Wang et al, Infocom 2000