2011

1. DCCP Evaluation for SIP Signaling
Agus Awaludin
Mohamad Fathurahman
Reza Primardiansyah
Riri Fitri Sari
Depeartment of Electrical Engineering, Faculty of Engineering
University of Indonesia, Depok 16424
E-mail : awaludin@ui.ac.id, mohamad.fathurahman91@ui.ac.id,
reza.primardiansyah@ui.ac.id, riri@ui.ac.id

2. Agenda
• Motivation
• Background
• Development of DCCP_SIP Agent and
SIP_DCCP Application Traffic
• Simulation of SIP over DCCP
• Result and Analysis
• Conclusion

3. Motivation
• Objective
– Evaluate the performance impact on the use of DCCP for SIP Signaling
• Approach
– Utilize Network Simulator 2 (NS-2) for simulation of SIP based call
setup over DCCP and UDP
– Compare the impact of both Transport Signaling Protocol on Call Setup
Delay and Call Drop Rate
• Result
– Adding new required Agent and Traffic for SIP over DCCP, based in
previous work of independent SIP library
– Challenges on further investigation on proving the simulation result
that DCCP can minimize the Call Drop Rate

4. Background
• NGN Protocol
• SIP
• UDP
• Explicit Code Notification
• Active Congestion Management
• DCCP

5. NGN Protocol
• Generally, these protocols are grouped into Signalling Transport Protocol,
Bearer Control Protocol, and Call Control Protocol.
– Signalling Transport Protocol serves transport layer signaling while serving
higher level services.
– Bearer Control Protocol controls NGN media gateways.
– Call Control Protocol is used to control call setup.
• Adopting the future multimedia services, the next generation of fixed
and mobile network evolved from Next Generation (NGN) and IP
Multimedia Subsytem (IMS) framework to Evolved Packet System (EPS)
as the meeting point of NGNs
MTP1
IP
TCP
H.248 MGCP SIP
MAC
SS7 H.248 MGCP SIP
MTP3
MTP2
I
S
U
P
SCTP
IP
MAC
SCTPUDP
IP
MAC
UDP
IP
MAC
UDP
1
2
3
4
5
6
7
OSI
IP
H.323
MAC
H.323
TCPUDPM2UA
M3UA
SCCP
TCAP
INAP
• Next Generation Network uses
several protocols for
interconnection between
existing communication
components, hardware or user
alike.

6. SIP (RFC 3261)
• Session Initiation Protocol is a
Call Control Protocol that used
for builds, modify and tear down
one or more participant session
• SIP is IETF main protocol for
multimedia and data control
signaling framework.
• SIP defines the following
entities in its protocol:
– Location Service
– Proxy Server
– Redirect Server
– Registrar
– User Agent (Client and Server)
• SIP has a significant role as the
main signalling and call control
protocol on all next generation
framework

7. UDP (RFC 768)
• UDP is a simpler message-based connectionless protocol.
– Unreliable : no concept of Acknowledgment, retransmission or
timeout
– Not ordered : the order in which they arrive cannot be predicted
– Lightweight: no ordering of messages, no tracking connections
– Datagrams: Packets have definite boundaries, read operation at the
receiver socket will yield an entire message
• Until now UDP is agreed as an optimal IP transport protocol for SIP.
• The unreliable characteristics of UDP brings an issue regarding the
possibilites of call drop caused by the congestion on the network,
leading the imposibility to implement reacheability of
telecommunication service.

8. Explicit Code Notification (RFC3168 )
• Extention to the TCP/IP that notify the network congestion through
marking packets
• Use an ECN fields in the IP header with two bits, ECN-Capable
Transport (ECT) codepoints '10', ECT(0), and '01', ECT(1), indicate
that the end-points of the transport protocol are ECN-capable
• Senders are free to use either the ECT(0) or the ECT(1) codepoint to
indicate ECT, on a packet-by-packet basis
• The not-ECT codepoint '00' indicates a packet that is not using ECN.
• The CE codepoint '11' is set by a router to indicate congestion to the
end nodes

9. AQM
• AQM is a technique that consists in dropping or ECN-marking
packets before a router's queue is full
• AQM drops packets based on the average queue length exceeding a
threshold, rather than only when the queue overflows.
• AQM can set a Congestion Experienced (CE) codepoint in the packet
header instead of dropping the packet, when such a field is
provided in the IP header and understood by the transport
protocol.
• The use of the CE codepoint with ECN allows the receiver(s) to
receive the packet, avoiding the potential for excessive delays due
to retransmissions after packet losses.

10. DCCP
• Unreliable flows of datagrams
• Reliable handshakes for connection setup and teardown
• Reliable negotiation of options
• Mechanisms to avoid holding state for unacknowledged connection
attempts and already-finished connections
• Congestion control incorporating Explicit Congestion Notification (ECN)
[RFC3168] and the ECN Nonce [RFC3540]
• Acknowledgement mechanisms communicating packet loss and ECN
information.
• Optional mechanisms that tell the sending application which data packets
reached the receiver, and whether those packets were ECN marked,
corrupted, or dropped in the receive buffer
• Path Maximum Transmission Unit (PMTU) discovery [RFC1191].
• Two mechanisms of modular congestion control mechanisms : TCP-like
Congestion Control [RFC4341] and TCP-Friendly Rate Control (TFRC)
[RFC4342].

11. DCCP
Specifying the client and server ports, the service being requested,
and any features being negotiated, including the CCID
Exchange DCCP-Data packets, DCCP-Ack packets acknowledging that data, and, optionally,
DCCP-DataAck packets containing data with piggybacked Acknowledgements
indicating that it is willing to communicate with
the client
client sends a DCCP-Close packet acknowledging the close
server sends a DCCP-CloseReq packet requesting a close
server sends a DCCP-Reset packet with Reset Code 1, "Closed", and clears its connection state
acknowledges the server's initial sequence number
and returns any Init Cookies in the DCCP-Response

12. Effort on this Project
• Development of DCCP_SIP Agent
• SIP_DCCP Application Traffic
• Simulation of SIP over DCCP

13. DccpSIPAgent Agent
• Include all packet structure type in DCCP :
• hdr_dccp , hdr_dccpack , hdr_dccpreset ,hdr_dccpreq
, hdr_dccpresp, hdr_dccpdata , hdr_dccpdataack ,
hdr_dccpclose , hdr_dccpclosereq
• Addtional packet type structure
• hdr_SIP

14. NS Application
• Additional application traffic sip_dccp for NS2
SIP library
• DCCP_SIP_Traffic
• INVITE_Timer_
• RINGING_Timer_
• OK_Timer_
• BYE_Timer_
• SIP_DCCP_Traffic
• SIP_DCCP_TrafficClass

15. Simulation of SIP over DCCP and UDP

16. Simulation
• System Services Overview
– Consist of , 2 SIP Proxy (send and receive SIP message), 1 EXP sorce
node, 1 destination node (SINK), 4 node act as a router node
• Performace Metrics
– Average call setup delay of SIP Signalling flow, Call drop rate of SIP
signalling flow
• System and Workload Parameter
– Type of transport layer protocol ( UDP, DCCP ) , Provides a comparison
of performance and behaviour of various transport layer protocols for
SIP Signalling
– Number of SIP invite packet initiation per second , Provides a
comparison of signalling transport protocol impact on call drop
avoidance and call setup delay
• Factor and Values
– Transport layer protocol: UDP, DCCP
– Number of call per second: 5, 10, 20, 40
– Simulation Times : 3600

17. TCL Configuration
Setup Node T01,T02,L01,L02,PR1,PR2,Voice1,Null2, test_1 ,test_2
Setup dccp_test_sink: Agent/Null,
attach to test_2
Setup link between Nodes
Setup voice_test : Application/Traffic/Exponential,
attach to dccp_test
Setup dccp_1 and dccp_2: Agent/DCCP/DCCPSIP,
attach to PR1 and PR2
Set sip_1 and sip_2: Application/Traffic/SipDccp,
attch to dccp_1 and dccp_2
Setup dccp_test : Agent/DCCP, attach to test_1
Connect link between dccp_test and dccp_test_sink
Connect link between dccp_1 and dccp_2
at 0.0 generate traffic form application sip_1, sip_2 and voice_test
at finishtime stop application sip_1, sip_2 and voice_test
flush-trace and close all trace fileExit simulation
Set New SimulationSet trace and its files

18. Simulation Step

19. Result
0.165
0.17
0.175
0.18
0.185
0.19
0.195
5 10 20 40
callsetupdelay(s)
number of call(calls/sec)
DCCP UDP
DCCP UDP
N/s CALL RETRAN
S
CALL RETRAN
S
5 18036 0 12038 0
10 35130 0 23512 0
15 69246 0 45889 0
20 134089 0 93038 3325
Call
Rate
DCCP UDP
Average Std Dev Average Std Dev
5 0.18424 0.01173 0.17583 0.01439
10 0.18488 0.01174 0.17664 0.01444
20 0.18642 0.01196 0.17807 0.01450
40 0.18980 0.01242 0.18064 0.01481
70 0.18908 0.01238 - -
80 0.19285 0.01779 - -
Call Setup Delay Call Drop Rate

20. Discussion
• Case of DCCP Call rate 70 and 80 call/sec simulations use 5 minute
simulated time, yielding INVITE count 110969 and 125386, respectively,
without retransmission.
• This result may indicates that the congestion control implemented in DCCP
affect this signalling transport protocol to trasnmit SIP messages in case
of link congestion.
• In case of UDP, the simulation shows that at the Call rate of 20 call/sec,
INVITE messages retransmission occures. This indicate that there is a link
congestion and UDP do not have any mechanism to detect and deal with
it, and continuesly send the SIP message which leads to call drop
• This result indicates that UDP has, in average, less call setup delay than
DCCP. But DCCP has lower deviation giving better predictability.

21. Conclusion
• SIP has became the signaling protocol standard
on IP based telecommunication services.
• In this paper we have shown that DCCP has
strong characteristics that make it preferrable as
transport medium for SIP compared to UDP.
• The characteristics shown here are very low drop
rate and lower performance variation. We can
not see packet drop even in 80 call/second, twice
the rate where UDP drops