Call Setup Delay Modelling for Internet Telephony

1

• Call Setup Delay Modelling for Internet Telephony
• Dr. Tony Eyers
• TITR
• University of Wollongong
• Australia
• June, 1999

2
Where is Wollongong?
3
Research at Wollongong

• Wollongong University is regarded by the Industry
  as Australias premier ITT RD site
• The Institute for Telecommunications and
  Information Technology Research (TITR) operates
  within the University
• TITR has successfully undertaken over 13 million
  worth of RD for Industry during the past 5 years
• Around 50 full time researchers (including
  graduate students)
• Major industrial funding sources include
  Telstra, Motorola, Vodafone, Ericsson, BNR
• Research areas QOS issues for fixed and mobile
  networks, Audio coding, Security

4
Internet Telephony QOS

• Major focus on protocol development
• H.323, SIP/SDP
• RTP
• Gateway Location Protocol (GLP)
• Variable QOS
• As yet, no standard definitions
• IETF work underway to adapt ITU performance
  targets
• Current work on Internet voice QOS
• focus on UDP delay over public Internet
• Current work on Internet call setup delay
• some IETF drafts on IP signalling transport
• Elawid97 considers delay performance of a
  Lucent H.323 exchange

5
Problem Statement

• Determine Internet Telephony Call Setup delay
  distribution, over public Internet
• Measure Post Dial delay, ie between sending Setup
  message and receiving Alerting message
• Key parameters
• propagation delay
• queueing delay
• retransmission delay
• Processing delay not considered
• Aim compare SIP and H.323 setup delay
  performance
• key difference recovery scheme for lost messages
• SIP uses UDP, with timeout/retransmission
  mechanism
• H.323 uses TCP

6
Current Objectives for Call Setup Delay

• ITU Rec E.721 (1988)
• Mean post dial delay ? 3 seconds
• 95th percentile for further study
• ITU rec Q.709
• maxm number of STP/SPs for national/international
  component of connections
• ITU rec Q.725 (and Telcordia GR-1364)
• mean and 95th percentiles for switch response
  delay (ie IAM, ANM message processing)
• ITU Q.706
• STP message transfer delay
• New IETF draft combines these to form call setup
  delay targets
• eg large country 95 of connections have mean of
  3040-3158 msec, 95th ile 3947-3615msec

7
Call Setup Delay Observations

• Signalling Queueing delay not included in IETF
  draft
• Queueing delay includes transmission/retransmissio
  n delays
• SS7 queueing delay targets outlined in ITU rec
  E.733
• IETF call setup delay target implies routing and
  resource reservation
• My study ignores these, focuses on queueing
  delays only
• results provide a lower bound for Call Setup delay

8
Call Setup SIP
INVITE
PROVISIONAL RESPONSE
Message lost
timeout
INVITE
PROVISIONAL RESPONSE
Call Established
9
Call Setup SIP

• Provisional response retransmissions prompted by
  INVITE arrivals
• an optional mechanism is provided for provisonal
  response timeouts
• Final response messages always timeout
• Final responses also retransmitted when
  retransmitted INVITES arrive
• SIP timeouts
• 500 msec initially
• Retransmissions increase timeout by factor of two
• Maximum value 4 seconds
• Retransmissions stop after 7 attempts

10
Call Setup H.323 (Fast Connect)
TCP SYN
TCP SYN
TCP ACK
SETUP
CONNECT
Call Established
11
H.323 Call Setup

• TCP connection establishment adds additional
  round trip
• propagation delay
• SYN retransmission delay
• SYN, SETUP, CONNECT use standard TCP timeouts
• TCP timeouts
• Recommended initial value 3 seconds (RFC 1122)
• Some implementations start at 6 seconds
  Stevens94, Solaris allows initial timeout to be
  set
• Timeout value increases by a factor of two for
  each retransmission
• Maximum number of retransmissions varies between
  implementations

12
Simulation Modelling Scenarios

• 1) SIP INVITE - Provisional Response
• messages can pass through stateless proxies
• 2) SIP INVITE - Redirect Server, then INVITE -
  Provisional Response
• 3) H.323 Fast Connect
• TCP connection setup
• Exchange H.323 SETUP/CONNECT messages
• TCP timeouts assumed to be the same as the SIP
  ones

13
UDP Delay the Surveyor Project

• Run byAdvanced Networks and Services
• Measures one way UDP delay
• Currently 38 sites (mostly USA, some in Europe,
  Korea, New Zealand)
• Each site exchanges 4x40 byte UDP packets each
  second (2 each way)
• One way delay measured, resolution 50 usec
• Packet loss also recorded
• Surveyor site provides
• delay/loss histograms for each day, for all site
  pairs (measurements began in 1997)
• located at http//www.advanced.org/csg-ippm/
• Have been able to access the Surveyor traces for
  this project
• provide delay/loss for each UDP packet

14
Simulation Methodology

• Periods of up to 1 hour are examined
• Instantaneous Delay/Loss probabilities
  constructed from trace records
• two state error model used
• 200 sample and 20 sample moving windows
  maintained
• if 20 sample window has one error or less,
  current error prob. calculated from previous 200
  samples
• otherwise bad state assumed, error prob.
  calculated from 20 sample window
• Simulated Calls then arrive
• 50/sec, poisson call arrivals
• Call Setup Delay distribution/Call loss rate
  recorded over simulated interval
• Statistics for a one hour period generated from ?
  6000000 calls

15
Case Study

• Simulation runs over the first 90 business days
  in 1999
• 60 minutes per day starting at 1600
• Source Destination pairs
• New York-Boston
• New York-Chicago
• New York-West Coast
• New York-Hawaii
• Variations
• All calls visit a redirect server in Washington
  DC
• All calls visit a redirect server in Washington
  DC, then transit a proxy server in Indiana
• H.323 (eg TCP)
• Plots show 0th percentile () and 95th
  percentile of call setup delay (o)

16
New York/Boston
17
New York/Chicago
18
New York/West Coast
19
New York/Hawaii
20
New York/Boston (DC redirect)
21
New York/Chicago (DC redirect)
22
New York/West Coast (DC redirect)
23
New York/Hawaii(DC redirect)
24
New York/Boston(DC redirect,via Indiana)
25
New York/Chicago(DC redirect, via Indiana)
26
New York/West Coast(DC redirect, via Indiana)
27
New York/Hawaii(DC redirect, via Indiana)
28
New York/BostonTCP comparison
29
New York/ChicagoTCP Comparison
30
New York/West CoastTCP Comparison
31
New York/HawaiiTCP Comparison
32
Conclusions

• 95th percentile of Call setup delays mostly under
  1 second
• relatively small sample
• missing days may hide poor results
• relies on error probability modelling assumptions
• 95th delay percentile determined by error
  threshold
• as additional paths are added (ie redirect
  servers/proxy servers), increased error
  probability eventually raises 95th percentile
• TCP shows, in some cases, a marked increase in
  95th delay percentile
• due to increased error probability arising from
  connection setup
• TCP delay will increase markedly if standard TCP
  timeout values used

33
Future Work

• This project
• Extend experiments to consider
• TCP/UDP performance during very high error
  periods
• Full H.323 call setup
• Develop analytical model for delay/loss
• based on mean error rate
• Determine effect/prevalence of bursty errors
• Related Projects
• Determine targets for signalling message
  transport delay (as a component of overall call
  setup delay)
• Design procedures for dedicated IP signalling
  networks

34
New York-Indiana
35
New York-Boston(error window 600)
36
New York-Boston(error window 4)
37
New York-Chicago(error window 600)
38
New York-Chicago(error window 4)