تجزیه و تحلیل عملکرد و بهبود PR-SCTP ​​برای پیام های کوچک

PR-SCTP, a partially reliable extension of SCTP, provides a flexible QoS trade-off between timeliness and reliability for application traffic. However, the performance of PR-SCTP can be affected by certain traffic characteristics and network scenarios. We previously proposed an NR-SACK based optimization for PR-SCTP. In this work, we extensively evaluate and analyze the performance of PR-SCTP with NR-SACKs using different network scenarios. Moreover, we compare the performance of our NR-SACK based PR-SCTP with existing transport protocols for syslog traffic. In the evaluation, we use real syslog traces from an operational syslog system. The results indicate that NR-SACK based PR-SCTP significantly improves the overall message transfer delay as compared to SCTP and TCP.

The transport layer provides several end-to-end communication services such as multiplexing, reliability and flow control for applications. TCP and UDP are the most common protocols at this layer. However, to facilitate Internet telephony, a new transport protocol called the Stream Control Transmission Protocol (SCTP) [55] was defined by the IETF Signaling Transport (SIGTRAN) working group. Although SCTP was initially designed to address TCP’s shortcomings [26] in transporting telephony signaling (i.e. SS7) messages over IP-based networks, IETF later standardized it as a general purpose transport protocol for the Internet. Different OS kernel implementations such as FreeBSD, MAC OS X, Linux and Windows (SctpDrv4) include SCTP. Services such as flow control, congestion control and reliability in SCTP overlap with SACK TCP [39]. However, unlike TCP, SCTP supports additional advanced transport services like multi-streaming, multi-homing, partial ordering and partial reliability that application developers can utilize to define future applications. TCP and UDP serve disjoint sets of applications. They have an all or nothing approach to the reliability requirements of applications. TCP gives a fully reliable service for applications such as email, file transfer and web browsing that do not require timeliness. In contrast, UDP is commonly used for DNS resolution and time services that do not impose reliability but rely heavily on fast transport. However, a different set of applications including for instance real time multimedia distribution require services that fall between what TCP and UDP provide. Since TCP places reliability over timeliness, loss recovery during congestion periods can increase the end-to-end delay, which may violate the real time requirements of these applications. In consequence, applications that favor timeliness over reliability rely on UDP. However, the lack of congestion control in UDP may lead to congestion collapse in the Internet if the usage of these applications grows continuously [24]. Congestion control mechanisms are often implemented at the application layer. However, congestion control itself is not a trivial problem to solve and requires extensive testing and maturity before being deployed [25]. Furthermore, UDP provides no guarantees for the delivery of data. This is again problematic for applications such as real time multimedia that often use high compression, i.e., low bit rate encoding. For example, the Real-time Transport protocol (RTP) [51] on top of UDP does not retransmit lost packets. In this case, loss of important data may result in poor play back quality at the receiver. All these shortcomings in TCP and UDP lead to the development of partially reliable transport protocols that give a flexible trade-off between timeliness and reliability for an application. With partial reliability it is possible for an application to define reliability requirement per application data unit. This is useful for any application that generates data of heterogeneous priorities. If some of the data has relatively higher importance than the rest, overall end-to-end delay can be reduced if only important data are considered during loss recovery or when network resources are congested. For instance, time sensitive data are only useful at the receiver if they are delivered before their deadline. In this case, avoiding retransmission of expired data can improve the application performance. All in all, if the loss rate in the network does exceed the applications’ sensitivity to loss, partial reliability can improve application performance [37]. PR-SCTP [53] is a partially reliable extension of SCTP. By using PR-SCTP, it is possible to give varying levels of reliability according to the heterogeneous QoS requirements of individual application data units. In this case, a specific reliability level dictates when PR-SCTP should stop (re)transmission of the associated data. An application may thus trade timeliness for reliability, since this reliability level is specified at the application layer. This could be particularly useful when, for instance, the availability of network resources is dynamic. Several applications, including real time audio or video streaming [6], [42], [59] and [60], IPTV transmission [33] and SIP signaling [61], have been shown to benefit from PR-SCTP. Currently, several IETF working groups such as Real-Time Communication in WEB-browsers (rtcweb) [2] and [32] and IP Flow Information Export (IPFIX) [8] are considering PR-SCTP for partial reliability. In contrast to previous work on PR-SCTP, our research shows that the improvement when using PR-SCTP can be limited in several circumstances. In our earlier work [47] and [48], we showed that packet based buffering at the network may degrade application performance when application message sizes are small. In this case, the loss rate per application byte is increased, which degrades application throughput. Moreover, when small messages are bundled into a SCTP packet, for instance, due to congestion control, loss of this packet introduces bursty loss. In this particular instance, the key mechanism in PR-SCTP, the Forward Cumulative TSN (forward_tsn) mechanism, becomes inefficient. We identified this problem in [47] and the results of our further experiments with various traffic characteristics in [48] verified the inefficiency. We therefore proposed an optimization of PR-SCTP that uses Non-Renegable Selective Acknowledgement (NR-SACKs) [3] and [63]. Results of our small scale experiments in [48] suggested a significant improvement of application performance when using NR-SACKs in PR-SCTP. In this work, we extensively evaluate and analyze the performance of NR-SACK based PR-SCTP for different network scenarios. Moreover, we evaluate NR-SACK based PR-SCTP as a transport for the syslog system [20]. In the evaluations, we use real syslog traces from an operational network. Our evaluations show that the modified PR-SCTP can better trade timeliness for reliability as compared to SCTP, TCP and UDP. The remainder of the paper is organized as follows. The background to partial reliability and related work on PR-SCTP are described in Section 2. In Section 3, the forward_tsn inefficiency is described using an illustrative experiment. Our proposed NR-SACK based optimization for solving the inefficiency in the forward_tsn mechanism is described in Section 4. The implementation and performance evaluation of our solution are also described in this section. Section 5 discusses our study on syslog and the performance evaluation of NR-SACK based PR-SCTP for syslog. Finally, concluding remarks are given in Section 6.

In this work we have evaluated the performance of NR-SACK based PR-SCTP for different network scenarios. Due to congestion control the inefficiency from the forward_tsn mechanism in the existing PR-SCTP is likely to occur when application messages are small with heterogeneous reliability requirements and bundled into packets. Existing PR-SCTP is highly inefficient during loss recovery of such packets. NR-SACK based PR-SCTP reduces the loss recovery time in the investigated scenarios. In the paper, we also proposed PR-SCTP as a transport for event logging applications such as syslog. By using PR-SCTP, important log messages can be prioritized over normal messages when network resources are congested. Overall, application performance can be improved using a suitable trade-off between timeliness and reliability. Furthermore, prioritized retransmission to handle congestion related loss in logging systems has previously been suggested in [58]. Our study of the syslog application scenario suggests that its traffic characteristics are susceptible to the forward_tsn inefficiency in the existing PR-SCTP if network congestion occurs. According to our trace based evaluations, NR-SACK based PR-SCTP significantly improves the performance of the syslog application in this scenario. Although our analysis shows that applications generating small messages are scenarios where the forward_tsn inefficiency is likely to occur, the possibility of the inefficiency in the case of bigger messages may also occur. For instance, consider a scenario where a number of outstanding and large messages are lost during a handover. If those messages have mixed reliability requirements, existing PR-SCTP will also perform poorly. We expect that NR-SACK based PR-SCTP will perform better in such a scenario as well. As a continuation of our work, we aim to modify the SCTP send buffer management functionalities to also discard messages with expired lifetimes. We see it as a further improvement to the proposed NR-SACK based PR-SCTP. In addition, we also see the need for an extension of the syslog protocol to enable the use of PR-SCTP as the transport. The mapping of reliability requirements for different types of log messages to different PR-SCTP services is particularly a part of our future work. The results presented in the paper are all based on experimental evaluations. Another interesting extension of our work is to find a mathematical model that can capture all the factors that impact the performance of the PR-SCTP protocol with or without NR-SACKs. Modeling PR-SCTP performance has some major difference with modeling work described in [65], [66], [67] and [68]. Many of the works do not include all the protocol details to determine a suitable model. In our case, PR-SCTP performance is largely influenced by the forward_tsn mechanism during the loss recovery. The mechanism is influenced by the particular loss pattern in the network, the number of messages that are bundled in a packet, the distribution and placement of the messages in a packet, which particular PR-SCTP policy is being used at the sender, etc. We include the modeling as a future work in our research agenda.