DCCP Evaluation for SIP SignalingAgus Awaludin
Mohamad Fathurahman Reza Primardiansyah
Riri Fitri Sari
Depeartment of Electrical Engineering, Faculty of Engineering
University of Indonesia, Depok 16424 E-mail : [email protected], [email protected],
Agenda
• Motivation• Background• Development of DCCP_SIP Agent and
SIP_DCCP Application Traffic• Simulation of SIP over DCCP• Result and Analysis• Conclusion
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
Background
• NGN Protocol• SIP• UDP• Explicit Code Notification• Active Congestion Management• DCCP
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
ISUP
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.
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
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.
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
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.
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].
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
Effort on this Project
• Development of DCCP_SIP Agent • SIP_DCCP Application Traffic• Simulation of SIP over DCCP
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
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
Simulation of SIP over DCCP and UDP
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
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
Simulation Step
Result
5 10 20 400.165
0.17
0.175
0.18
0.185
0.19
0.195DCCP UDP
number of call(calls/sec)
call
setu
p de
lay(
s)
DCCP UDPN/s CALL RETRAN
SCALL RETRAN
S5 18036 0 1203
80
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
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.
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
Top Related