1

Working Group on Ad-Hoc Networks

Reliable Server Pooling for

Ad-Hoc Networks

M. Ümit Uyar, City College of CUNY

Mariusz Fecko, Telcordia Technologies, Inc.

Murray Hill, NJ

February 5, 2003

Prepared through collaborative participation in the Communications and Networks Consortium sponsored by the U.S. Army Research Laboratory under the Collaborative Technology Alliance Program, Cooperative Agreement DAAD19-01-2-0011

2

Reliable server pooling (RSP)

Objective: Increase system availability by viewing a pool of redundant information sources as a single transport endpoint

Benefits:• clients can get service even if one or more servers fails• underutilized servers can provide relief to nearby overloaded servers• switchover when QoS drops; sustaining sessions through switchovers

Client view:pool user (PU)

(client) server pool ID: pool handle

pool user(client)

Actual systempool elements (PEs)

PE

PEPE PEPE

PE

client’s RSP layer requests

pool handle/pool elements

mapping from its Home Name Server

3

RSP architecture and protocol stack

Key components and issues• signaling protocols• server selection• transport and security state transfer (?)• load sharing and server fault management• transparent connection/session migration (?)

PE(i) PE(j)

PE(k) PE(l)

… …

NS

PU

(4)(2)

(3)

(1)Applications:

RSP-blindRSP-partially-aware

RSP-fully-aware

RSP API

RSP

Mapping (shim)

SCTP/TCP/UDP

4

RSP scope

Loosely-coupled, open architecture• high survivability: server pools may span several network domains• does not attempt to provide complete fault-tolerant computing

Defining properties• maps a single communication-destination name to multiple routable and

reachable transport endpoints to increase the availability of distributed software-server entities registered under that name

• reliability services, ranging from simple server selection to a fully automatic session-failover capability, can be designed and added using RSerPool as a distributed, open platform

Outside core scope, but work is ongoing• fully transparent session-failover capability• keeping data integrity among servers• data replication techniques in ad-hoc networks

5

RSP in ad-hoc networks

IETF RSerPool WG is defining an architecture and protocols for RSP• Endpoint Name Resolution Protocol (ENRP) and Aggregate Server

Access Protocol (ASAP)• management and maintenance of the entire (flat) server pool

namespace provided by Name Servers (NSs)• lightweight, best-effort design

Is emerging IETF RSerPool applicable to ad-hoc networks?• IETF focuses on fixed, wired networks, and telephony applications• nodes are highly mobile, have limited processing power, are capable of

rapid self-configuration and autoaddressing of nodes and interfaces• is best-effort, lightweight approach sufficient for server resources that

are constrained and dynamic in MANETs?• mobility issues: network partitioning, local vs global name spaces,

dynamic vs static home server• impact on lower layers (routing, MAC) needs to be considered

6

Our approach

Evaluate IETF architecture and protocols through simulation• performance, scalability, resilience to stress conditions

Equip the architecture with mobility solutions • replace fixed elements with dynamic ones (e.g., home name server)• introduce local name spaces to tackle network partitioning• eliminate excessive signaling overhead by making the protocols

mobility-aware

Introduce “enhanced” architecture• distributed server selection and session-admission control• membership of pools based on managing dynamic server resources

•degree of readiness (DR): the number of associations that a server (from a pool) is willing to sustain at a certain level of QoS

• server may belong to different server pools, which can be formed (or taken down or merge/split) dynamically, at varying DRs

7

Simulation capabilities

Realistic evaluation must be performed in multi-layer wireless system

CCNY developed ns-2 simulation testbed that includes:• full implementation of IETF RSerPool protocols (ENRP + ASAP)• integration of MAODV for multicast• movement pattern selection (frequency, speed)• transmission pattern selection (antenna model, transmission range)• ongoing or planned

•group mobility models (Reference Point Group Mobility, Mobility Vector)• integration with UD SCTP ns-2 model

ENRPAgent

ASAPAgent

MAODVRouting

SimplifiedSCTP

RSP-awareCBR APP

Deterministic/StatisticalError Model

Wired/WirelessScenarios Definition

NS-2

8

Results for the IETF RSerPool

Hunting for home name server Successful transmissions

among Name Servers

Ratio of data packets to

control messages

Everything works fine for wired and stable networks; not so for mobile

and dynamic ones

9

Evaluation of IETF approach

Problems for wireless and mobile• namespace synchronization: name servers communicate successfully only 3-18% (90% for

wired) due to network partitioning• huge signaling overhead: only 3-6 as many data packets as control messages (1,300 for

wired)•hunting for home server accounts for 50% of control messages•exchange of info among NSs for 25%

• false server deregistrations: temporary movement of operational server out of transmission range interpreted as failure

Alternative mechanisms designed and evaluated:• replace hunting for home name server with advertisements

•overhead reduction ranges from 22% to 28%• make PE failure detection less aggressive (heartbeats, distinguishing between failed and

temporarily out of range)

10

Alternative mechanism: Server heartbeats

Original mechanism

(3) (1)

PU1

NS1(PU1’s home)

PE2PE1

Pool

(4)

(5)(2)

NS2(PE2’s home)

(4) (2)

PU1

NS1(PU1’s home)

PE2PE1

Pool

(1)

(5)(3)

NS2(PE2’s home)

(6)

(6) (7)

60-100% reduction in false server deregistrations

PE heartbeat mechanism

11

Quantifying RSP benefits

Lost (a) vs (a,b) sustained sessions

Session Sustainability Gain (SSG): relative increase in the system's ability to admit and run a session until completion

SSG measurements for mobile networks:• assumption: at each switchover, we can migrate the session• "binary" sustained vs lost: 10-29%• "reclaimed" session lifetime: 23-42%

(a)

tf

tc(b)

tf

tcf1 f1 f2 f3

tl

(c)

tf

tc

f1 f2 f3 f4

tl=tf

12

Dynamic (re-)configuration

Management of pool resources based on• periodic exchanges of aggregated information and requirements of the

pools• information about the network health from bandwidth brokers and

mobility events from mobility agents• server X advertises its capability set as <ST, SP, DR>, where ST is

server type, SP is server priority, and DR is degree of readiness

Example• server X sends periodic advertisements {<SIP,1,1000><HTTP,2,500>}• DRSIP=1000 and DRHTTP=500 can change between advertisments,

depending on changing server characteristics such as battery life, etc.• DRs are dynamically adjusted and used to perform admission control

based on server resources• server resources (I.e., server membership in pools) readjusted

dynamically to provide end-to-end quality for the service being requested by PU

13

Server selection (distributed, QoS-based)

In resource-constrained environment, the best-effort policy to offer server pool resources may lead to • degradation of service to the already existing sessions• increase in the number of switchovers if individual servers become

overloaded• impaired ability to perform successful switchovers or start new sessions

if server pools become overloaded• best-effort policy (in other words, common sharing policy) results in a

very high number of unsuccessful session attempts when the network resources are stressed [TON2001-Beard]

Four approaches to server selection are being investigated• pool guard channels• utility-based server-resources allocation• prioritized server-resources allocation• distributed fault localization techniques

14

Example Network

R

AP

PEPE

PE

R R

R

APPE

PE

PE

R

hub

PE PU

R

AP

PE

PU

ENRP

ENRP

ENRP

ENRP

MANET 1 MANET 2 MANET 3

PU

PU

PU

PUPU

Backbone Network

ENRP Name Server(Endpoint Name Resolution Protocol)R Router

PU Pool User (Host/Client)hub Hub

AP Access PointPE PE Pool Elements (each in different pools)

single node that is PE in two poolsPE PE

PU

PE PE

15MANET 2MANET 1

R

R R

R

R

hub

PE PU

R ENRP

ENRP

ENRP

ENRP

Backbone Network

APPE

PE

PU

PU

Experiment Scenario 1: PE movement

PEPE

PU

MANET 3

PE

The PE for the “pink” pool moves from MANET 2 to 1• PE is assigned a new IP address• PE must reregister with the ENRP server. • Sessions in progress at PUs rely on SCTP mobility to maintain session• PUs in pink pool may need to switchover to a new PE for new sessions

The PE for the “pink” pool moves from MANET 2 to 1• PE is assigned a new IP address• PE must reregister with the ENRP server. • Sessions in progress at PUs rely on SCTP mobility to maintain session• PUs in pink pool may need to switchover to a new PE for new sessions

PE

APPE

PUPU

PU

SCTP mobility used for in-progress session

RSerPool switchoverused for new sessions

PU

PE PE

AP

16

R

R R

R

R

hub

PE PU

R ENRP

ENRP

ENRP

ENRP

Backbone Network

APPE

PE

PU

Experiment Scenario 2: PU movement

MANET 2

AP

PE

PU

MANET 1

A PU using both services moves from MANET 1 to 2• PU is assigned a new IP address• Transactions in progress at PU rely on SCTP mobility to maintain session • PU may need to switchover to new PEs in green and pink pool,

and may need to select a new primary ENRP server.

A PU using both services moves from MANET 1 to 2• PU is assigned a new IP address• Transactions in progress at PU rely on SCTP mobility to maintain session • PU may need to switchover to new PEs in green and pink pool,

and may need to select a new primary ENRP server.

PE

PU

MANET 3

APPE

PUPU

PUPE

PU

PE PE

17

R

R R

R

R

hub

PE PU

R ENRPENRP

ENRP

ENRP

Backbone Network

APPE

PE

PU

Exp Scenario 3: Failure of co-located Rtr/ENRP

MANET 2

AP

PU

MANET 1

PU

Router and ENRP server co-located on single assetFailure of that asset causes AP to failover to backup

connection to router (e.g. on a lower bandwidth radio channel)PEs in MANET 1 must failover to backup ENRP serverWhat is the effect on PUs, PEs in MANET 1?

Router and ENRP server co-located on single assetFailure of that asset causes AP to failover to backup

connection to router (e.g. on a lower bandwidth radio channel)PEs in MANET 1 must failover to backup ENRP serverWhat is the effect on PUs, PEs in MANET 1?

PE

PE PE

MANET 3

APPE

PUPU

PUPE