SCTP Support For P2P Applications With TomP2P · (Stream Control Transmission Protocol) with respect to real-time conferencing, stored media streaming and possibilities of NAT traversal

SCTP Support For P2P ApplicationsWith TomP2P

Jonas WagnerZurich, Switzerland

Student ID: 11-716-230

Supervisor: Dr. Thomas Bocek, Bruno RodriguesDate of Submission: December 12, 2017

University of ZurichDepartment of Informatics (IFI)Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi

MA

ST

ER

TH

ES

IS–

Com

mun

icat

ion

Sys

tem

sG

roup

,Pro

f.D

r.B

urkh

ard

Stil

ler

Master ThesisCommunication Systems Group (CSG)Department of Informatics (IFI)University of ZurichBinzmühlestrasse 14, CH-8050 Zürich, SwitzerlandURL: http://www.csg.uzh.ch/

Zusammenfassung

Media Streaming wird im heutigen Internet immer wichtiger. Viele Peer-to-Peer (P2P)Anwendungen wie Skype erfordern mehr als Datenstreaming, sondern auch Echtzeit Vi-deotelefonie. Dieser Bereich uberschreitet die Grenzen von TCP (Transport Control Pro-tocol) und UDP (User Datagram Protocol) und fuhrt zu einem unglucklichen Kompromisszwischen Verzogerung und Datenverlust (Jitter). Diese Arbeit vergleicht zunachst die Ver-wendung von TCP, UDP und SCTP (Stream Control Transmission Protocol) in Bezugauf Echtzeit Videotelefonie, Datenstreaming und Moglichkeiten der NAT-Traversierung.Der Vergleich zeigt, dass weder TCP noch SCTP fur die Durchfuhrung von Echtzeitkon-ferenzen im Internet geeignet sind. Daher wird in der Arbeit die Verwendung von SCTPvia uber SCTP vorgeschlagen. SCTP ermoglicht es dem Benutzer, Verbindungen zu op-timieren, um sowohl Echtzeitkonferenzen als auch gespeicherte Medienstreams uber dasInternet durchzufuhren. Zweitens wird die vorgeschlagene Losung in TomP2P implemen-tiert und integriert. Die Implementierung wurde erfolgreich im Internet getestet.

i

ii

Abstract

Media streaming is getting more and more important in today’s internet. Many Peer-to-Peer (P2P) applications like Skype require more than just real-time conferencing, but alsostored media streaming. This scope exceeds the limits of TCP (Transport Control Proto-col) and UDP (User Datagram Protocol) and leads to an unfortunate trade-off betweendelay and data loss (jitter). This thesis first compares the use of TCP, UDP and SCTP(Stream Control Transmission Protocol) with respect to real-time conferencing, storedmedia streaming and possibilities of NAT traversal. The comparison shows that neitherTCP nor SCTP are well-suited to do real-time conferencing in the Internet. Therefore,the thesis proposes the use of SCTP encapsulated over UDP. SCTP enables the user tooptimize connections to do both, real-time conferencing as well as stored media stream-ing via the Internet. Second, the proposed solution is implemented and integrated intoTomP2P. The implementation was successfully tested in the Internet.

iii

iv

Acknowledgments

I’d like to thank Dr. Thomas Bocek and Prof. Dr. Stiller for their support and help whileI was diseased from February till May. Thank you both, that could restart this thesis atthe time I recovered. Also, thank you very much for the opportunity to write this thesisat the Communication Systems Group of the University of Zurich.

v

vi

Contents

Zusammenfassung i

Abstract iii

Acknowledgments v

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Description Of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 3

2.1 Peer-To-Peer Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 How Does A NAT Work? . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.2 NAT Traversal In P2P Networks . . . . . . . . . . . . . . . . . . . 4

2.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.2 TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.3 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.4 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Streaming Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 Stored Media Streaming . . . . . . . . . . . . . . . . . . . . . . . . 11

vii

viii CONTENTS

2.4.2 Live Media Streaming . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.3 Real-Time Conferencing . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Comparison Of NAT Traversal With SCTP And TCP Fast Open . . . . . 12

2.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.2 Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.3 Hardware and Test Setup . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.4 Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.5 Test Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.6 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.7 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5.8 Solution Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Related Work 19

3.1 UDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Libjitsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5 Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Requirements 23

4.1 Must-Have . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Should-Have . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Nice-To-Haves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4 TomP2P Integration Constraints . . . . . . . . . . . . . . . . . . . . . . . 24

CONTENTS ix

5 Design 25

5.1 libjitsi sctp4j . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.1 usrsctp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.2 sctp4nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 SCTP Encapsulation Over UDP . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.1 Shield sctp4j Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.2 Extended Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6 Implementation 31

6.1 Package net.sctpnat.origin . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 Scpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.2 SctpSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1.3 JNIUtils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.4 SctpDataCallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.5 SctpAcceptable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.6 SctpNotification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2 Package net.sctpnat.core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2.1 SctpChannelFacade . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2.2 SctpChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2.3 SctpChannelBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.4 SctpMapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.5 SctpPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.6 SctpTimeoutThread . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.3 Package net.sctpnat.connection . . . . . . . . . . . . . . . . . . . . . . . . 37

6.3.1 SctpConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3.2 SctpDefaultStreamConfig . . . . . . . . . . . . . . . . . . . . . . . . 38

x CONTENTS

6.3.3 NetworkLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3.4 UdpClientLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3.5 UdpServerLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4 Package net.sctpnat.util . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4.1 SctpInitException . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4.2 SctpUtils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.5 usrsctp Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.6 Junit Testing Of sctp4nat . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.7 Integration Into TomP2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.7.1 ChannelServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.7.2 ChannelClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7 Evaluation 47

7.1 Test Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2 Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2.1 Test Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2.2 Test Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.3 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.3.1 Internet Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.3.2 Consistency Test Results . . . . . . . . . . . . . . . . . . . . . . . . 52

8 Summary, Conclusion, And Future Work 53

8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Bibliography 57

Abbreviations 61

List of Figures 61

CONTENTS xi

List of Tables 64

A Installation Guidelines 67

B Iptables Router Configuration Shell Commands 69

C Linux Bash Test Scripts 71

D Contents of the CD 73

xii CONTENTS

Chapter 1

Introduction

TomP2P is a Peer-to-Peer (P2P) network, which includes communication over the well-known protocols Transport Control Protocol (TCP) and User Datagram Protocol (UDP).The network was developed by members of the Communication Systems Group (CSG)of the University of Zurich (UZH). TomP2P is a Distributed Hash Table. Its featuresinclude network discovery mechanisms to overcome Network Address Translation (NAT)boundaries (e.g. Hole Punching) [42, 46].

1.1 Motivation

Today many people are using voice over IP (VoIP) applications. Such applications requirethe underlying network to support real-time conferencing. Real-time conferencing requireslow delay and very few data loss (jitter). TomP2P only supports TCP and UDP. Theconsequences are that either the TomP2P needs to accept larger delays or a critical amountof data loss. Therefore, a new approach is needed to handle VoIP traffic. At the same timethis approach should also allow transmitting data without data loss, because a TomP2Pneeds to be able to transfer data. Thus, the solution approach is required to do threethings. First, it should be able to transfer data properly without data loss. Second, itshould be able to handle real-time conferencing without having too much jitter or too longdelays. Third, the protocol has to work in the Internet and therefore be able to overcomeNAT boundaries [37, 42].

For this cause, this thesis introduces a target use-case. This use-case is a video and VoIPapplication similar to Skype [33]. Additionally, a peer should be able to chat and transmitfiles over the target application. Nevertheless, such an application is not part of this thesisbut remains a use-case for the underlying network, which will be TomP2P. The approach,this thesis takes, is tested in the in the Internet. The test showed if the new approachis able to handle the three requirements (file-streaming, real-time conferencing and NATtraversal).

1

2 CHAPTER 1. INTRODUCTION

1.2 Description Of Work

This thesis consists of three major parts. First, it evaluates common transport protocolsaccording to the three requirements from Section 1.1. The evaluation shows, which pro-tocol is most suited for these requirements. Furthermore, this thesis evaluates specificallySCTP and TCP Fast Open and compares them to each other. Second, the best suitedprotocol is implemented in TomP2P, such that TomP2P is able to support applicationslike Skype in future. Third, this thesis tests, if the proposed solution works in the Internet.

1.3 Thesis Outline

This master thesis consists of eight chapters. Chapter 1 introduces the reader to the keytopic of this thesis. Chapter 2 lays the theoretical background for this thesis, especially forthe comparison between SCTP and TCP Fast Open. Related work is listed in Chapter 3.The comparison from Chapter 2 suggests a solution, which is specified in Chapter 4 anddesigned in Chapter 5. The implementation of the solution approach and the integrationinto TomP2P are described in Chapter 6. In Chapter 7, the solution approach is testedin the Internet. Afterwards, the thesis covers a summary, conclusion and Future Work inChapter 8.

Chapter 2

Background

This chapter covers the theoretical background for this master thesis. Section 2.1 explainsPeer-to-Peer (P2P) networks. Section 2.2 describes the problems caused by NAT andmethods to overcome NAT (e.g. Hole Punching). Afterwards, Section 2.3 explains TCP,UDP and SCTP. These three protocols are applied to the streaming requirements from[37] in Section 2.4. Section 2.5 compares TCP Fast Open and SCTP with respect to NATtraversal.

2.1 Peer-To-Peer Networks

A Peer-to-Peer (P2P) network consists of multiple peers. Each peer represents serverand client at the same time. In most P2P networks, peers are required to share theirresources (e.g. services, data, ect...) equally and communicate directly with each other.P2P networks can be classified as pure, hybrid or centralized P2P networks. A pureP2P network works in a fully decentralized manner (e.g. Gnutella 0.4). Gnutella 0.6 isconsidered a hybrid P2P network, since it distinguishes between nodes (peers) and super-nodes (super-peers). Super nodes are peers, which are better reachable and have highbandwidth capacities. For instance, the super nodes relay traffic between normal Gnutella0.6 nodes if necessary. An example for a centralized P2P network was Napster. Napsterconsisted of a centralized index server, and many peers. The centralized index serverserved the purpose of searching network content, e.g. music files, and held the addressof the offering peer. To exchange files, the peers in the Napster network contacted eachother directly [16, 18, 26].

2.2 Network Address Translation

Network address translation, NAT for short, is widely used across the Internet. It isintegrated on many routers and firewalls to masquerade the users endpoint information(Internet Protocol (IP) address and port). IP masquerading used by NAT allows users

3

4 CHAPTER 2. BACKGROUND

to share a single IP address across an entire private network with their own IP addressspace. Many NAT devices (imagine your home router) combine the use of NAT andfirewall. This way, NAT users are able to block any unwanted traffic, because they blockincoming traffic without a valid NAT mapping. On the one hand this grants more security,because, the endpoint decides, to which other endpoint it connects. But on the other hand,this behaviour makes other endpoints unable to contact endpoints using NAT [46].

2.2.1 How Does A NAT Work?

A valid NAT mapping is created if a user of the private address space sends out traffic tothe global address space (e.g. call to a webserver). The mapping consist of the following:

1. Source IP address and port of the private address space endpoint

2. Destination IP address and port of the global address space endpoint

3. Translated source IP address and port of the private address space endpoint

4. Translated destination IP address and port of the global address space endpoint

Figure 2.1 shows, how a valid NAT mapping is created. In the figure, the client (1.2.3.4)lies in its own private address space, while the server (8.8.8.8) is located in the globaladdress space. In this example the client sends a packet to the server. It is assumed,that the NAT used by the client is running in port-preserving mode as described inSubsection 2.2.2. Further, it is assumed, that the NAT type is a Port Restricted ConeNAT and the server does not use a NAT device. Once the client sends out the packet, thepacket first reaches its NAT device. Since the packet is determined to leave the privateaddress space, the NAT replaces the client’s source address (1.2.3.4) with its own sourceaddress (5.6.7.8). Additionally, the NAT takes the port used by the client and uses itfor the mapping. Afterwards, the mapping looks as shown in Figure 2.1. Eventually, thepacket reaches the server. The server, is now able to communicate with the client via theexchanged IP address and port (5.6.7.8:1000).

2.2.2 NAT Traversal In P2P Networks

There are four known NAT types. Namely, Full Cone NAT, Address Restricted ConeNAT, Port Restricted Cone NAT and Symmetric NAT. The first NAT type does notblock incoming traffic. Thus, it omits the additional security of blocking incoming traffic.The address Restricted Cone NAT only restrict the IP address of possible endpoints inthe global address space. But most of the routers are using Port Restricted Cone NAT,which restricts outside traffic to use the same source and destination IP address andport whenever packets need to be exchanged. In areas, which need additional securitymeasures, Symmetric NAT are used. Symmetric NAT do not reuse the port used by theclient, but disguise it by using a random port. This way, the initial port used by the clientcannot be guessed by any entity in the global address space [29].

2.2. NETWORK ADDRESS TRANSLATION 5

Figure 2.1: Network Address Translation Example [46]

If NAT are used in P2P networks, they impede direct connections of peers. TomP2Puses several different mechanisms to overcome NAT to directly connect peers with eachother. Namely reverse connection setup [34], UPnP [2, 50], NAT-PmP [7] and UDP HolePunching [34]. All of these mechanisms allow a peer to overcome NAT boundaries, butare not applicable in many cases. A reverse connection setup can only be done, if onlyone of two peers is using a NAT and there is a relay peer available, which is connectedto the peer using a NAT. UPnP is a piece of software running on many NAT devices,but is not always automatically enabled. Further, it suffered from security flaws in thepast (e.g. [17]) making it less attractive to be enabled. UPnP and NAT-PmP also lackthe support for multiple layers of NAT. Thus, in such a case, the concerned peers arenot able to communicate directly. NAT-PmP is not used widely and is mostly supportedon Apple devices. Because of the downsides of UPnP, NAT-PmP and reverse connectionsetup, TomP2P peers are either forced to use relaying or, if possible, Hole Punching.

Hole Punching

Hole Punching is an algorithm, which is able to interconnect two entities using a NATby forcing the NAT to create the required mappings. The algorithm depends on theNAT type and the protocol used by the endpoints. For example, UDP Hole Punching ismore successful than TCP Hole Punching, because unanswered UDP NAT mappings lastmuch longer (at least 30 seconds, see Section 2.5) than unanswered TCP NAT mappings(3 seconds, see Section 2.5) (measured with Netfilter Iptables). Therefore, it is easierto implement UDP Hole Punching than TCP Hole Punching. Additionally, SymmetricNAT are very hard to overcome, since the peers either are able to guess the random portmappings chosen by their NAT or are very resource intensive (e.g. [15]). For those reasons,TomP2P uses UDP Hole Punching, which is able to overcome Port Restricted Cone NATwith port-preservation. Figures 2.2 and 2.3 show the UDP Hole Punching process. In theshown scenario, there are three hosts. Two peers behind a NAT (Port Restricted ConeNAT with port-preservation), A and B and a Server S. S does not use a NAT. Thereforeit is publicly available. A and B. Assume, client A wants to establish an association with


(a) Before Hole Punching (b) The Hole Punching Process

Figure 2.2: UDP Hole Punching Process [34]

Figure 2.3: After Hole Punching [34]

2.3. PROTOCOLS 7

client B. Without Hole Punching, the NAT of client B blocks the incoming connectionapproach from A. The Hole Punching process (as shown in Figure 2.3) works as follows:

1. A assigns an endpoint consisting of an IP address and a port.

2. A sends its endpoint information to B via S.

3. S forwards the endpoint information of A to B

4. Client B reads the forwarded information of A and assigns its own endpoint.

5. Afterwards, B sends this information back to A. At the same time, B starts to sendmessages to A in order to create the necessary NAT mapping.

6. Once A received the correct endpoint information of B, it is able to connect to B.

2.3 Protocols

This section explains the well-known protocols TCP and UDP. Additionally, the sectionalso discusses TCP Fast Open, which is an extension of TCP and SCTP. The respectivesubsections focus on the structure of the protocols (headers) and the features provided bythem.

2.3.1 TCP

The Transmission Control Protocol (TCP) is a connection-oriented protocol, which runson top of the IP. It is called reliable, because it guarantees the transmission of its packets.Each packet in TCP is uniquely identified with a sequence number and retransmitted, ifconsidered lost. TCP offers its users a full duplex byte stream with congestion and flowcontrol. Congestion control means that TCP is using a network congestion-avoidancealgorithm, which determines the speed, with which TCP transmits data. TCP deliversits data in a strict order. That means, that a receiver of a file transferred via TCP needsto buffer all packets with a higher sequence number until the preceding lower numberedpackets arrive. Since TCP is able to discover the path maximum transmission unit (MTU),it is able to send packets efficiently over the Internet [8, 38].

Figure 2.4 shows the common TCP header. A TCP packet consists of 24 bytes headerdata including source and destination ports as well as the sequence number, to identify thepacket. The acknowledge number summarizes the already received data. Further thereare fields for TCP header length, congestion and flow control, security and associationstatus transmission. These fields are explained more deeply in [38]. The options fieldprovides the user of TCP with the possibility to supplement a tcp header with its ownneeded fields.


Figure 2.4: Common header of TCP packets [38]

2.3.2 TCP Fast Open

TCP fast open is an extension of the TCP protocol. A traditional TCP handshake requiresthree packets, namely SYN, SYN ACK and ACK. TCP Fast Open extends this three wayhandshake and adds the exchange of a cookie for SYN and SYN ACK, resulting in SYN+ cookie and SYN ACK + cookie. Once the cookie has been exchanged between thetwo endpoints, they are able to omit the final ACK. To connect to each other they onlyhave to exchange their cookies. This saves one third of the traditional connect time. Themechanism works, as long as the cookies are not expired [6].

2.3.3 UDP

The User Datagram Protocol (UDP) is, unlike TCP, a connection-less protocol. ThereforeUDP does not require any handshake to transmit packets to other UDP endpoints. Ad-ditionally, UDP does not track its packets, it sends them over the network without caringif its packets arrive or not. UDP does not contain congestion and flow control and doesnot transmit its packets in a strict order. Thus, the UDP protocol is considered fasterthan TCP, but less reliable. UDP allows full-duplex data transmission. Unlike TCP,UDP supports the preservation of message boundaries of its packets. Thus it does notneed to split data across multiple packets and therefore UDP prevents unnecessary packetoverhead. A UDP (see in Figure 2.5) header consist of eight bytes containing source anddestination ports, packet length and a checksum [27, 39].

Figure 2.5: Common header of UDP packets [39]

2.3. PROTOCOLS 9

2.3.4 SCTP

In 2001, the Internet engineering taskforce (IETF) introduced the Stream Control Trans-port Protocol (SCTP). Evolved from a telephony signaling protocol for IP networks, SCTPoffers features, which are designed with telephony signaling and multimedia applicationsin mind.

Figure 2.6 shows a generic SCTP packet with the common header. The common headerconsists of source and destination port, a verification tag and a checksum. The verificationtag is a random value chosen at the setup of the association to identify stale packets fromprevious associations with the same endpoint. The checksum field in the common headerserves the purpose of message integrity. In SCTP, every piece of information is transportedin so called chunks. The content of a chunk is defined by its chunk type. This means, ifa user likes to send a piece of data, the data is transmitted in a chunk with chunk typeDATA. Another example would be the INIT message, which is used for setting up anassociation. It is defined by the INIT chunk type. The flags in the flags field serve thepurpose of configurability of the specific stream association [5, 35].

Figure 2.6: SCTP packet with chunks [5]

While UDP and TCP provide byte-stream transmission services, SCTP provides a message-oriented transmission service. Alike TCP, SCTP is a connection-oriented protocol, whichis considered reliable. But SCTP is also able to transmit its messages in a partially re-liable way, meaning that the user is able to specify the number of retransmission trials.SCTP supports ordered and unordered data transmission. Thus, a user is able to chooseaccording to the application needs. Alike TCP, the SCTP specification contains flow andcongestion control. Likewise, SCTP supports path MTU discovery (like TCP). SCTPconfirms its messages with selective acknowledgements (ACKs) [5, 35].

SCTP has a four-way and a two-way handshake. The four-way handshake consists ofthe following four messages visualized in Figure 2.7. INIT and INIT ACK are analogousmessages to TCP SYN and SYN ACK. COOKIE ECHO and COOKIE ECHO ACK areneeded, because the SCTP association requires their endpoints to exchange a cookie,which can be used in future, to shorten the handshake. Once the association is closed, thecookie remains for a user determined amount of time. A two-way handshake is done, ifboth endpoints hold a valid cookie from each other. In this case, INIT and INIT ACK canbe omitted. Thus, the two-way handshake only consists of COOKIE ECHO and COOKIEECHO ACK [5, 35].


Figure 2.7: SCTP handshake [5]

SCTP also supports Multistreaming and Multihoming. Multistreaming is achieved, byallowing different data streams on a single connection. This is possible, because SCTPmessages are able to contain multiple different chunks. Figure 2.8 shows that two SCTPhosts are able to open several different data streams to one another. The streams negotiatethe association terms during the association setup. Each stream is flagged with a streamid. The data from the specific stream is dispatched by the user [5, 35].

Figure 2.8: Multistreaming between Host A and Host B [5]

Multihoming is a feature, which allows an SCTP endpoint to be IP address independent.SCTP uses a specific path algorithm to explore the most efficient path between twoendpoints. This algorithm recalculates periodically, if there is a more efficient path touse. For instance, it checks if an additional IP address was added or removed. Thisfeature grants the user an adaptive failover mechanism if a link using a certain IP addressfails, while granting a robust changeover of redirecting the SCTP traffic over an alternativepath. Multihoming is not usable with current NAT devices, since they are not able tohold multiple IP addresses for the source and destination addresses. Additionally, theNAT devices are also not able to adapt to SCTP Multihoming path changes. Therefore,on many SCTP implementations, Multihoming is not implemented [1, 5, 35].

2.4 Streaming Requirements

[37] mentions three different types of streaming. Stored media streaming, live mediastreaming and real-time conferencing. The three types of streaming are discussed in

2.4. STREAMING REQUIREMENTS 11

Subsections 2.4.1, 2.4.2 and 2.4.3.

2.4.1 Stored Media Streaming

A common form of stored media streaming is Video on Demand (VoD). For a user watchinga video over its web browser (using Hyper Text Transport Protocol (HTTP)), delay isnot much of a problem, since the entire video, or a sufficiently large part of it, needs tobe downloaded upfront. Thus, this type of streaming is usually using TCP, because ittransfers data without any loss. Since SCTP optionally implements traffic and congestioncontrol, it covers the features of TCP. Therefore, SCTP is also considered a valid optionfor stored media streaming [5, 37].

UDP is inferior to TCP and SCTP in a stored media streaming context. Since UDP suffersfrom packet loss, it needs to either use mechanisms, which compensate this behaviour.Possible mechanisms would be Forward Error Correction (FEC) or interleaving. FECadds more overhead to the stream, since it sends duplicate data to avoid loss. Interleavingsuffers from data loss, but tries to minimize loss of large data chunks.

2.4.2 Live Media Streaming

Live media streaming (e.g. broadcasting live television over the Internet) may requirelarge amounts of connections. Therefore, it depends on the available server infrastructureand the amount of consumers, if TCP or UDP is used. The more consumers, the morelikely the use of UDP, because it is able to handle multicast much better than TCP. Theconsumer of a live stream is more likely to accept some lost packets than very long delaysor even connection losses. For the same reasons as TCP, SCTP is not a likely option forlive media streaming with large amount of consumers [5, 37].

2.4.3 Real-Time Conferencing

A good example for real-time conferencing are voice over IP (VoIP) calls. The mostcritical part for such calls are on the one hand the amount of jitter and on the other handthe amount of latency. [37] states, that the telephone network allows a one-way latencyof up to 150 milliseconds for an acceptable usage of real-time conferencing. Table 2.1shows the latency evaluations on the protocols mentioned explained in Section 2.3. Sincepacket loss (jitter) is important for the quality of the call, it is listed in the table. Further,[37] states, that bandwidth usage is an crucial part for servers and clients doing real-time conferencing. The reason for this lies in the dependency of bandwidth capacity andlatency. The more traffic in a fixed size network exists, the more latency is added to thetransmission because of network congestion. This thesis assumes, that there is enoughbandwitdh available. Thus, the criteria does not appear in Table 2.1.

Since TCP and its extension TCP Fast Open transmit their packets in a strict order(see 2.3.1), larger buffer sizes have to be considered. Therefore, in a real-time conferencing


TCP TCP Fast Open UDP SCTPBuffer size (latency) High High Low Can be bothPacket loss (jitter) No No Yes Can be both

Table 2.1: Transport Protocols applied to Real-Time Conferencing requirements

context, both, TCP and TCP Fast Open suffer from long delays. But unlike UDP, they donot experience jitter, because they retransmit lost packets. However, both protocols needmore bandwidth, because on the one hand they retransmission creates more packets andon the other hand, TCP and TCP Fast open require one connection per client [37]. Thusfor the given context, TCP and TCP Fast Open are not considered desirable options.

UDP sends its packets only once. Therefore, the buffer sizes do not need to be large.Thus, UDP is able to keep the latency low. But since it sends its traffic unordered, therecipient can decide if waits for a certain packet or not. This is a more preferable optionthan the larger buffer size of TCP. If UDP is used in a Skype-like context, it suffers frompacket losses. But packet loss can be minimized with either enough bandwidth, Forwarderror correction or interleaving. Imagine a Skype video conference, where the participantswould have to wait for a single packet, which is dropped by one member of the call. Notonly would it add an overall delay to the call, the information contained in that singlepacket might not be needed anymore. Thus, for real-time conferencing, UDP is commonlypreferred over TCP [37].

Considering the criteria’s from Table 2.1, SCTP seems to be the most desirable option.SCTP is able to balance latency and jitter for the following reasons. First, SCTP supportsflow and congestion control, but does not enforce it. Second, it sends its traffic optionallyordered. Third, bandwidth usage can be controlled, because SCTP supports multiplestreams over a single association [5, 37].

2.5 Comparison Of NAT Traversal With SCTP And

TCP Fast Open

Sections 2.3 and 2.4 have shown, that TCP is considered well-suited for file-streaming,UDP is well-suited for real-time conferencing and SCTP is well-suited for both applica-tions. Since the goal of this thesis is to complement TomP2P with a protocol, whichis better suited for real-time conferencing than UDP and better suited for stored mediastreaming than TCP, two protocols, SCTP and TCP Fast Open, are investigated moreclosely. These two protocols are compared with respect to data loss (jitter), latency andNAT friendliness.The term NAT friendliness is an attribute to protocols, which signalshow well a certain protocol is able to overcome NAT devices.

2.5. COMPARISON OF NAT TRAVERSAL WITH SCTP AND TCP FAST OPEN 13

2.5.1 Requirements

The requirements for investigating on the NAT traversal techniques with SCTP and TCPfast open are the following. The respective protocol must support hole punching viaPort Restricted Cone NAT with port-preserving. More specificly, hole punching must besupported at least on Linux (Ubuntu 16.04) [51]) via netfilter Iptables [24] NAT imple-mentation.

2.5.2 Test Environment

To test the two protocols, TCP Fast Open and SCTP, the following software tools wereused.

Ubuntu 16.04

Ubuntu is an open-source Linux operating system based on Debian. It is developedand maintained by Canonical. Its long term support versions (e.g. 16.04) include fiveyear guaranteed support. Ubuntu is one of the most popular Linux operating systems.Therefore, the use Ubuntu as operating system for the investigation is justified [4, 51].

Netfilter Iptables And Conntrack

Iptables is an IP packet filter firewall with integrated NAT. It is used in many Linuxdistributions including Ubuntu 16.04, which this thesis uses. Iptables offers command-line configurability, which allows a user to setup a machine as a router, firewall or NAT ifneeded. Thus, the use of Netfilter Iptables is justified. The script used for both routersin the test environment can be found in Appendix B [24].

Netfilter’s Conntrack-tools is a command-line instrument to display the current NAT tableentries of the NAT table in use. The use of this tools makes sense, because it can be usedto track the NAT table’s entries. This is very important for Hole Punching [24].

SendIP

SendIP is a tool, which was originally written by Mike Kicketts of Project Purple [28]. Thissoftware tool is able to create transport layer packets via command-line input. The userof SendIP is able to configure the packets in order to test their behaviour in a computernetwork. SendIP runs on Debian and therefore also on Ubuntu. SendIP supports thegeneration of both, IPv4 and IPv6 packets. To test the NAT behaviour for the comparisonof TCP Fast Open and SCTP, SendIP was used to generate the needed packets [32].


Wireshark

Wireshark is a network monitoring software, which is able to monitor the network in-terfaces of a computer. While running on certain network interfaces it captures all thepackets sent and received by the computer using it. This software was needed to check ifpackets sent from one computer to another actually reached their destination [49].

2.5.3 Hardware and Test Setup

To test Hole Punching there are at least two hosts needed. The test setup was organizedas visualized in Figure 2.9. Two Lenovo ThinkPads (4GBs of RAM, Core Duo T9400 CPU[21]) with Ubuntu 16.04 were used as hosts. The hosts are referenced (see Figure 2.9) asthe two machines with IP addresses 10.0.0.2 and 10.1.1.2. Because the hosts need to usea NAT, two additional computer machines (2GBs RAM, Intel Core 2 Duo E8400 [22])were used. Each of the machines were configured with the Iptables Linux shell scriptmentioned in Subsubsection 2.5.2 (see also in Appendix B). The machines are visualizedin the Figure as routers with the name NAT 1 and NAT 2. At last, there is an additionalrouter providing DHCP services for NAT 1 and NAT 2. This router also interconnectsNAT 1 and NAT 2.

This test setup was simplified and did not use a server to exchange the port informationneeded for Hole Punching. This omission was justified, because the test environment waslocated in a local area network and the outgoing ports were determined beforehand. Forthis reason, a server, as shown in Figure 2.2 and 2.3 was not needed.

2.5.4 Investigation

This section consists of the description of the test scenario its results.

2.5.5 Test Scenario

In order to investigate on the NAT behaviour, the following test scenario was created:

1. Send a packet with the respective protocol from one host to the other one.

2. Monitor if the sending of the packet created a NAT table mapping.

3. Send a second packet with the respective protocol from one host to the other one.

4. Measure the time until the NAT table mapping is destroyed.

5. Send a third packet with the respective protocol from one host to the other one.

6. Manually respond to the packet from the other host by sending back a packet withthe same protocol.


Figure 2.9: Test setup for NAT behaviour investigation

7. Monitor if the reply packet created a NAT table mapping.

8. Monitor if the reply packet was received by the host, which send the initial packet.

The sending of SCTP packets was done with the following SendIP [32] command:

sendip -v -l 10 -p ipv4 -is 10.0.0.2 -p sctp -sI 7000 1.0.0.3 -ss 7000 -sd 7000

To send TCP packets, the second -p flag was set to tcp and the sI flag was removed, sincethis signaled the SCTP INIT chunk. For the IPv6 test, the first -p flag was set to ipv6.To monitor if the NAT mappings were created and for how long they remained, IptablesConntrack was used. The shell command conntrack -E listed all the needed informationfor the test scenario. Wireshark was used to monitor, if the reply packets actually reachedtheir destination.

2.5.6 Test results

Table 2.2 shows the results, which were measured by the test. As a complement to thetest subjects, UDP NAT behaviour also appears in the table.


TCP FastOpen

SCTPmanually

enabled SCTPUDP

NAT mapping createdcorrectly on NAT 1

Yes No Yes Yes

Time NAT mapping lasted 3 seconds No mapping 3 seconds 30 secondsNAT mapping createdcorrectly on NAT 2

Yes No Yes Yes

Reply packet received Yes No mapping Yes Yes

Table 2.2: Test results from the NAT test of SCTP and TCP Fast Open

The test results show, that TCP Fast Open is able to support Hole Punching, because,the reply packet was received by the initial sender. The TCP (either TCP or TCP FastOpen) mapping only lasted 3 seconds on the NAT, which is considered a problem. Inthe used test environment, 3 seconds are enough time to respond to a packet, but in thereal-world the network can be far more congested. Additionally, Hole Punching requiresat least two full round trip times (RTT) to work properly, since it involves a relay server.Thus, TCP and TCP Fast Open cannot be considered NAT friendly. Further, the manualcalculation of the TCP Fast Open Cookies is very hard to do, because it would requirethe user to decode and encode the TCP packets on the application layer.

The test showed, that plain SCTP packets could not be transmitted. Additional tests withdifferent NAT devices (AVM FritzBox! TP-Link, OpenWRT) revealed the same results.Iptables, as well as the mentioned NAT boxes ignored all SCTP packets and discardedthem. They did not create a mapping for SCTP traffic. Thus, not only is SCTP unableto use Hole Punching, it is impossible to use in the Internet if one of the hosts is usingone of the tested NATs.

The reason, why SCTP appears twice in the results table, is because Iptables is able tocreate NAT mappings after the user manually enables SCTP. After enabling SCTP inthe Linux kernel, both NAT mappings were created correctly. The time, which the NATmapping lasted is 3 seconds (like TCP). Thus, SCTP (if manually enabled) cannot becalled NAT friendly.

UDP is considered NAT friendly, because not only the NAT mappings are created cor-rectly, but the UDP mapping lasts 30 seconds on Iptables firewall. Considering thatmany of today’s NAT boxes are using Linux as a base, it can be assumed, that most ofthe commonly available NAT devices behave the same way.


2.5.7 Comparison

TCPTCP

Fast OpenUDP SCTP

SCTPvia UDP

Buffer size (latency) High High Low Can be both Can be bothPacket loss (jitter) No No Yes Can be both Can be bothNAT friendliness Low Low High Low High

Table 2.3: Table 2.1 complemented with the simplified results from Table 2.2

Considering the target use-case of this thesis (a VoIP application similar to Skype), itappears that none of the investigated protocols fulfills all the requirements stated inSection 1.1. Table 2.3 shows the (simplified) complemented outcome of the comparisonof the protocols explained in Section 2.3. The table reveals, that the main trade-off existsbetween NAT-friendliness and jitter (packet loss). Or, in simple words, either one getsfiles transmitted correctly or one can call each other qualitatively well.

2.5.8 Solution Approach

Given that none of the protocols mentioned in Section 2.3 fulfills all requirements, thisthesis takes the approach of combining two protocols with each other. The InternetEngineering Taskforce (IETF) proposes the encapsulation of SCTP packets with UDPheaders [41]. This mechanism is advantageous for the following reasons. It is able to makeSCTP work in the Internet, because UDP is a Internet standard and NAT devices, if notexplicitly disabled, support this protocol. Further, the encapsulation of SCTP packetsmakes SCTP NAT friendly and UDP Hole Punching possible. Thus, the configurabilityof SCTP respective to real-time conferencing and stored-media streaming combined withthe NAT friendliness of UDP are fulfilling the requirements of this thesis target use-case.For this reason this thesis focuses on the implementation of SCTP via UDP and integratesthis solution approach into TomP2P.

Using SCTP via UDP means, that all UDP packets need to be dispatched and decodedbefore they can be forwarded to the SCTP counterpart. This procedures are time andresource consuming. Also, the procedures add complexity to each application using them.Thus, using SCTP via UDP suffers from more delay and more resource consumptioncompared to plain SCTP or UDP. Additionally, using UDP headers adds more Overheadto each SCTP packet. But, since UDP headers are only eight bytes long, this overhead isconsiderably small compared to TCP or plain SCTP.


Chapter 3

Related Work

3.1 UDT

The main purpose of UDP-based Data Transfer (UDT) is to handle high-speed file transfertraffic. Based on UDP, it covers many features of TCP like congestion and flow control.UDT claims to improve such mechanisms by making them faster. For instance, UDT onlysends negative ACK’s to avoid additional traffic. Additionally UDT claims to improvecongestion control by its own algorithm. Since the release in 2013, UDT has not foundwidespread use in the Internet. In February 2017, project Netty even deprecated theirpackages using UDT [20, 44, 52].

3.2 QUIC

Quick UDP Internet Connections (QUIC) is a protocol, which was designed by JimRoskind at Google. The first implementation of QUIC was released in 2012. In June2015, QUIC was submitted to the Internet Engineering Task Force (IETF) for the sakeof standardization. The IETF working group started its work in the same year. As ofJanuary 2017, QUIC is still in work at IETF and marked as an Internet-Draft. [19]claims, that QUIC accounts for more than 5% of Internet traffic in mid-2017. The pro-tocol features a short handshake, flexible congestion control, multiplexing, authenticatedand encrypted header and payload, stream and connection flow control an connectionmigration. Therefore, QUIC is similar to SCTP encapsulated over UDP. One of the maindifferences between the two protocols, SCTP and QUIC, lies in the handshake. QUIConly needs between zero and one RTT to set up a connection. SCTP uses between oneand two RTT’s [12].

19

20 CHAPTER 3. RELATED WORK

3.3 WebRTC

Web Real-Time Communication, or short WebRTC, is an open source framework, whichprovides browsers with the capability to directly connect to each other (in a P2P way).Further WebRTC offers an API, which lets the user transfer files or make audio andvideo calls. Initially, WebRTC was a project from Global IP Solutions. In 2010, Googlebought this company and made the project open source. In 2011, the first version ofWebRTC was released. In January 2015, WebRTC introduced that their communucationAPI, WebRTC Datachannels, use SCTP via UDP. Figure 3.1 shows the used protocolstack including SCTP and UDP. Analogous to this thesis, WebRTC combines the use ofSCTP and UDP to overcome NAT barriers in order to integrate the features of SCTP toits framework [13, 47].

Figure 3.1: The WebRTC datachannel protocol stack [13]

3.4 Libjitsi

Jitsi is an open-source platform, which provides API’s and libraries for developing VoIP,video conferencing and instant messaging applications. Jitsi also offers its own applica-tion as a reference implementation. Jitsi is mainly implemented in Java and thereforeconsidered platform independent. The first version of Jitsi was released in 2003. As ofNovember 2017, Jitsi is still extended and maintained. Jitsi includes several libraries. Oneof those libraries is used as a reference implementation for this master thesis. Namely,Libjitsi was used. Libjitsi contains a project called sctp4j, which uses usrsctp (UserlandSCTP) via Java Native Interface (JNI) [14].

3.5. DIFFERENCES 21

3.5 Differences

Although UDT supports reliable file transfer and is considered NAT friendly, it is not aviable option to use for this master thesis. UDT is not widely supported and does not offerthe configurability, SCTP offers. Thus, UDT is not optimized for a real-time conferencingcontext. Additionally, it remained an Internet Draft since the start of its standardizationprocess in 2003. Further, since Netty cancelled the support for UDT, it was decided notto use UDT for this thesis [20, 44, 52].

The QUIC protocol shares many similarities with the approach of this thesis (SCTPvia UDP). This thesis differentiates itself from QUIC, since it is forced to use the Javaprogramming language. Also, because QUIC is not yet an Internet standard, it is notwidely supported. At the time this thesis started, there was not yet a sufficiently stableversion of QUIC available in Java [12].

A major difference between WebRTC and this thesis, is that this thesis is required touse the Java programming language, because TomP2P is written in Java. Since the mainuse-case of WebRTC is to interconnect Browsers, the framework cannot be used efficientlywith TomP2P. As of November 2017, there is no plan to integrate WebRTC into Java.An additional difference is, that this thesis does not have the same protocol stack for itdoes not prescribe the use of higher level protocols than transport layer ones. Therefore,TomP2P lets the user decide, which protocols run on top of the provided SCTP via UDPprotocol [25, 42, 47].

This thesis uses the Libjitsi sctp4j project as a reference java implementation of SCTP viaUDP. The difference between Libjitsi and this thesis is that Libjitsi does not support allsix service primitives (e.g. reply) of connection-oriented protocols [40] in an Internet P2Pcontext. For instance, Libjitsi needs to know the endpoint information for each endpointupfront, which would not be possible in a P2P network. Therefore, this thesis extendsthe Libjitsi sctp4j project with the needed service primitives and adds features to it inorder to run SCTP via UDP in a P2P network like TomP2P [14].

22 CHAPTER 3. RELATED WORK

Chapter 4

Requirements

This chapter explains the requirements for the implementation of the solution approach(SCTP via UDP). Additionally it includes the requirements needed for the integrationinto TomP2P. This thesis implementation requirements are stated in user-stories. Theyare organized in must-haves (see Section 4.1), should-haves (see Section 4.2) and nice-to-haves (see Section 4.3). Additionally, constraints for the integration into TomP2P werealso added in Section 4.4.

4.1 Must-Have

[40] introduces six service primitives, which need to be supported by connection-orientedprotocols. These services are visualized in Figure 4.1.

Figure 4.1: The six service primitives [40]

The consequences for the design and implementation of SCTP via UDP are the following:

• A (TomP2P) peer must be able to connect to another peer via SCTP.

• A peer must be able to listen on a determined socket (IP address and port) to replyconnection attempts of other peers.

• A peer must be able to accept incoming connection attemps from other peers.

23

24 CHAPTER 4. REQUIREMENTS

• A peer must be able to (block) wait for incoming data.

• A peer must be able to send data to another peer via SCTP.

• A peer must be able to disconnect from an already existing association.

• A peer must be able to reply to a request from other peers on the same connectionas the request.

4.2 Should-Have

In the following list, the should-have requirements for this thesis are stated.

• A peer should be able to overcome NAT with SCTP via UDP.

• A peer should be notified, if a certain SCTP socket is already used.

4.3 Nice-To-Haves

The nice-to-haves for this thesis can be found in the list below.

• A peer should be able to transfer files bigger than 1MB to another peer withoutdata loss.

• A peer should be able to

• A peer should be able to perform reverse connection setup with SCTP via UDP.

• A peer should be able to perform UDP Hole Punching with SCTP via UDP

4.4 TomP2P Integration Constraints

For the integration of SCTP via UDP for TomP2P, the following constraints have to bemet

• Since TomP2P’s programming language is Java, the SCTP over UDP solution mustbe implemented in Java or contain an easy to use Java interface.

• TomP2P requires the SCTP via UDP solution to run on a single port. Therefore,the SCTP via UDP server must be able to create sockets and answer to associationrequests on its own.

Chapter 5

Design

In this chapter, the solution approach elaborated in Chapter 2 and the requirementsfrom Chapter 4 are considered for the design. The chapter consists of the explanation oflibjitsi sctp4j (see Section 5.1), the initial design for SCTP encapsulation over UDP (seeSection 5.2, the most important design decisions made for sctp4nat (see Section 5.3) andthe resulting UML class diagram (see Section 5.4).

5.1 libjitsi sctp4j

This thesis decided to choose libjitsi as a base for the following reasons. There was nonative Java SCTP encapsulation over UDP implementation available. Therefore, in orderto implement the suggested solution approach from Section 2.5, this thesis needed todesign and implement its own library to fulfill the thesis requirements. Libjitsi offeredfour out of six of the service primitives mentioned in this thesis must have requirements.Therefore, the decision was to extend libjitsi rather than to implement everything fromscratch [30].

Libjitsi consists of several parts. The part relevant for this thesis is the sctp4j project,which contains the respective Java classes. The most important class is called Sctp. Itcontains all methods, which call the usrsctp library via JNI. Also, usrsctp uses the Sctp

class for its callbacks to libjitsi. Additionally, Sctp stores the socket pointers of usrsctpto localize the assigned (virtual) sockets from usrsctp. The second most important classin sctp4nat is SctpSocket. This class represents the sctp socket in Java. Wheneverusrsctp assigned a socket, there is a SctpSocket instance, which represents this socket.SctpSocket also holds an instance of the UDP socket (see NetworkLink class) used forencapsulation as well as instances for usrsctp callbacks (see SctpDataCallback class) [30].

5.1.1 usrsctp

usrsctp is the reference SCTP via UDP implementation from [41] and [36]. This imple-mentation of SCTP via UDP omits the use of Multihoming, since Multihoming inhibits

25

26 CHAPTER 5. DESIGN

the NAT traversal of SCTP via UDP. usrsctp does not use real sockets on the localmachine, it only simulates them. Therefore, resources are saved. usrsctp offers all sixtransport service primitives, which are mentioned in Section 4.1. The reason why sctp4jmust access usrsctp via JNI is because usrsctp is written in the C programming language.

5.1.2 sctp4nat

In order to integrate SCTP via UDP into TomP2P it was necessary to create an ownproject, because the usrsctp sctp4j C files were required to use a different file path thanTomP2P supports. Thus, the necessary files from sctp4j were copied from the respectiveGithub repository and introduced into a new project called sctp4nat [11, 30, 31].

5.2 SCTP Encapsulation Over UDP

Following the approach suggested by Subsection 2.5.8 the protocol stack shown in Fig-ure 5.1. The stack provides each SCTP packet with a UDP header. This way, SCTPconnection are able to create NAT mappings on NAT devices. This also implies the useof UDP Hole Punching.

Figure 5.1: The designed protocol stack for SCTP via UDP connections.

The main idea of implementing the protocol stack visualized in Figure 5.1 is to redirectthe respective UDP traffic to its particular SCTP socket. Figure 5.2 shows the designedprocess of transmitting data between peers using SCTP via UDP. The figure’s scenariois the transmission of a data packet between a client and a server. The client starts theprocess by calling send(data) on its corresponding ClientSctpSocket. The ClientSctp-

Socket then forwards the data to usrsctp via JNI. usrsctp then creates the needed SCTPpackets and headers and returns them via a callback method called onConnOut(). OnceonConnOut() is called on ClientSctpSocket, it will call the corresponding UdpSocket,which is responsible for the network communication between the peers. ClientUdpSocketwill then provide each created SCTP packet with a UDP header and send it to the de-termined ServerUdpSocket. Once the UDP packet reached the ServerUdpSocket it isforwarded to the corresponding ServerSctpSocket, which then forwards it again to theserver usrsctp instance via JNI. usrsctp then decodes the packet and calls onConnIn()with the decoded data from the client. At last, the data from the client is forwarded fromthe ServerSctpSocket to the ServerPeer.

5.3. DESIGN DECISIONS 27

Figure 5.2: Simplified sequence diagram of the transmission of data between two peersusing SCTP via UDP.

5.3 Design decisions

According to the requirements of Chapter 4 and the solution approach from Subsec-tion 2.5.8 many design decisions were to be made. These design decision can be found inthe following subsections.

5.3.1 Shield sctp4j Classes

To use sctp4j without changing it too much, its classes needed to be shielded from the userof sctp4nat. Therefore a user is forced to use sctp4nat instances and methods to connecttwo peers to each other. The main benefit from this abstraction was, that if sctp4j addschanges or features in the future, sctp4nat is able to adapt to them more quickly.

As an interface to the user, the decision was to use the adapter pattern. This patternaims to convert an interface from a class into another (class) interface a client expects[10]. This way, it would be possible to combine the already existing features of sctp4jwith the missing service primitives from this thesis’ requirements. Further, the decisionwas to use the facade pattern to unify the access to the underlying sctp4j classes. Thebenefits of using this pattern are that the classes of the subsystem (e.g. the sctp4j classes)are shielded from the user. Further, using a facade simplifies the access for the client.Additionally, the user of the subsystem is only weakly coupled to it. This makes futurecode changes much easier fulfill.

5.3.2 Extended Features

Since Sctp4j does not fully support the reply service primitive, this feature needed tobe added. The main obstacle in designing this feature was to make sctp4nat buffer thesocket information in Java. The reason why sctp4j does not support reply is because, onthe one hand, it does not store information about the remote peer in its Java instances,


and, on the other hand, usrsctp does not require this information. Thus, the decisionwas to create a class called SctpMapper, which contains a map that stores IP address andport information of the remote user for a certain association. The consequences of thisapproach were, that each SctpSocket needed to be registered to be used properly. Thisadded complexity to the sctp4nat project, which is considered to be the lesser evil thannot to implement a must-have feature.

Derived from the should-have requirements, it was necessary to automate the NetworkLinkto automate the creation of SctpSockets on Java and C side. For this reason UdpServer-

Link was designed. The class was designed to run on a publicly known port. If a peerwould try to setup an SCTP association via this port, the class would automatically createa SctpSocket for this association. This way, sctp4nat is able to run on a single (fixed)port, which is required from TomP2P.

Since one of the requirements was, that a peer needed to be notified, if a port was alreadyused, this feature needed to be added to sctp4nat. The decision was to create a classcalled SctpPorts, which contained a map containing all the already occupied ports. Thisway, a user would be able to be notified, in case of assigning an SCTP port twice. Fur-ther, because each port on a system could only be used once, the decision was to makeSctpPorts implement the Singleton pattern [10].

5.4 Class Diagram

The design choices made in Section 5.3 lead to the class diagram visualized in Figure 5.3.The figure shows the five java packages, which were created for this thesis. The red packagerepresents the net.sctp4nat.origin package. It contains the classes, which needed tobe shielded from the user (see 5.3.1). The blue packet is called net.sctp4nat.core andcontains all the classes needed for the must-have features of this thesis. The main idea ofthe green net.sctp4j.connection package is to make the connection between two peersmore convenient. The grey package contains utility classes and exceptions. The classes inthese packages and their implementation is explained more closely in Chapter 6.

5.4. CLASS DIAGRAM 29

Figure 5.3: UML class diagram overview of the sctp4nat project


Chapter 6

Implementation

In this chapter, all critical classes of sctp4nat and their implementation are explained.Also, this chapter covers the testing and the integration of sctp4nat into TomP2P (see 6.7).

6.1 Package net.sctpnat.origin

This package consists of six classes, namely Sctp, SctpSocket, JNIUtils, SctpNotifi-cation, SctpDataCallback and SctpAcceptable. Since the design decision was to beable to adapt to changes of sctp4j, the classes were left as-is whenever possible. However,because these classes contained smaller bugs, small adjustments hade to be made to eithersupport necessary features of sctp4nat or to fix bugs in sctp4j. Figure 6.1 shows the originpackage and its classes.

6.1.1 Scpt

Sctp encapsulates the native usrsctp counterpart. It contains methods to initialize usrsctpand to deinitialize it. Also it encapsulates methods needed for the six service primitivesfrom [40]. Namely, Sctp contains connect(), listen(), accept() send(), onSctpIn()(which is receive) and shutdown() or close() (which represent disconnect). Further,Sctp is responsible for the creation and destruction of SctpSocket instances.

Sctp was adjusted in several ways. First, since shutdown and finish were not enabled,those features were enabled. Additionally, code adaptions had to be made in the corre-sponding c files to enable this feature in usrsctp, too. Second, since SctpMapper neededto keep track of all active SctpSockets, the conversion from the native socket pointer tothe Java SctpSocket instance had to be added. Third, several smaller errors in code hadto be corrected.

31

32 CHAPTER 6. IMPLEMENTATION

Figure 6.1: The net.sctp4nat.origin Package

6.1.2 SctpSocket

SctpSocket is the Java socket implementation of the corresponding usrsctp socket. Thisclass uses the respective usrsctp socket via Sctp. Therefore, it contains also methods forthe six service primitives. However, all these methods call Sctp to be executed on usrsctp.If there is a callback, SctpSocket is called by Sctp. Additionally to the service primitives,SctpSocket is also used for debugging and logging usrsctp. The inner interface Notifi-

cationListener cares about error and debug messages written out by the usrsctp library.NotificationListener listen for SctpNotifications and forwards them in its own call-back, which is represented in method onSctpNotification(). The possible notifications aredefined in usrsctp.

The class had to be adjusted for the use in sctp4nat. First, acceptNative() was changed,so that all incoming and outgoing association attempts are accepted by sctp4nat. Eitheron the first data packet sent or the first data packet received, acceptNative() is executed.Second, to know when a connection is established, shutdown, closed or lost, sctp4natneeded to be notified. For this reason, the default SctpNotificationListener will beoverwritten by every SctpChannel. Third, because sctp4nat is required to run on a singleport, it was necessary to modify onConnOut() and resolve the current SctpChannelFa-

6.2. PACKAGE NET.SCTPNAT.CORE 33

cade instance for the corresponding NetworkLink objects. Fourth, several minor bugswere detected and fixed.

6.1.3 JNIUtils

JNIUtils is responsible for loading the required JNI libraries for the operating system(OS), which is running underneath. The class contains the method loadLibrary(), whichloads the compiled C library for JNI. This class was not adjusted by this thesis.

6.1.4 SctpDataCallback

SctpDataCallback was adjusted, such that the callback method (onSctpPacket()) con-tains the SctpChannelFacade, on which the packet was sent on. This adjustment isneeded, because it enables the service primitive reply in the sctp4nat project.

6.1.5 SctpAcceptable

SctpAcceptable was not in the initial implentation of sctp4j. This thesis added theinterface for the sake of shielding the package from the user. The interface is used in classSctpSocket, in method onSctpNotification(). Prior to the change, the method returnedan instance of SctpSocket. This instance was exchanged with the interface. Thus,SctpSocket implements SctpAcceptable. SctpAcceptable only contains one method(acceptNative()), which provides the possibility of accepting a connection attempt fromanother SCTP endpoint.

6.1.6 SctpNotification

This class originates from the initial implemetation of sctp4j. There were no changes madeto this class apart from making some strings publicly available. The class is responsiblefor parsing incoming notification strings from the usrsctp counterpart. These strins arethen prepared and forwarded to the responsible SctpSocket.

6.2 Package net.sctpnat.core

The core package consists of the following seven classes: SctpChannelFacade, Sct-

pChannel, SctpChannelBuilder, SctpMapper, SctpPorts and SctpTimeoutThread. Theclasses are visualized in Figure 6.2. The main goal of this package was to implement thecore features needed for the implementation of SCTP via UDP as this thesis suggests inSubsection 2.5.8.


Figure 6.2: The net.sctp4nat.core Package

6.2.1 SctpChannelFacade

SctpChannelFacade is the facade of the facade design pattern mentioned in Subsec-tion 5.3.1. The interface publishes several different methods. First, it implements fourpossible send() methods. These methods are non-blocking and return a Promise object,which contains a callback once the method was executed. Second, the close() methodcloses the underlying SctpSocket and releases its assigned resources on usrsctp. Further,the corresponding entries on SctpMapper and SctpPorts are also removed. Third, thesetSctpCallback() method specifies the callback, which is called whenever a SCTP packetarrived on the respective SctpSocket (see also Subsection 6.1.4). Fourth, getRemote()retrieves the InetSocketAddress including IP address and port information of the remoteendpoint. Fifth, method shutdownInit() initializes the shutdown procedure on usrsctp. Itcauses the associated endpoint to close its corresponding SCTP connection. After callingshutdownInit(), a user should call the close() method. Sixth, method setNotificationLis-tener() replaces the assigned NotificationListener with an own one. realWorld

6.2. PACKAGE NET.SCTPNAT.CORE 35

6.2.2 SctpChannel

SctpChannel implements the SctpChannelFacade interface. Therefore, it implements allthe methods mentioned in Subsection 6.2.1. The main goal of the class is to extend thefeatures of SctpSocket to fulfill the required features for SCTP via UDP. SctpChannelis shielded from the user, because of the implementation of the facade pattern. Thus,a user will only get a SctpChannelFacade interface to interact with SctpChannel. ASctpChannel holds a SctpSocket instance, which is used for interacting with usrsctp.Additionally, a SctpChannel knows its NetworkLink, SctpMapper, the remote endpointand NotificationListener. These objects are needed since the class also implements theadapter pattern. SctpChannel adapts the behaviour of SctpSocket, Sctp, SctpMapperand SctpChannelFacade.

Nine of the 19 methods of SctpChannel are implementations of SctpChannelFacade (seeSubsection 6.2.1). The connect() method is responsible for establishing an associationwith the specified remote SCTP endpoint. The following code listing shows this method.After the check if the usrsctp native library is initialized, the method cares about setupand registration of the future association. connect() also uses a SctpNotificationLis-

tener (see addNotificationListener() in Figure 6.2) in order to know if the associationis established. Further, the listener is also called if the association status changes (e.g.timeout, shutdown, close). The method returns a Promise object, which is notified oncethe association is established or an error occured. After the creation of the Notifica-

tionListener, connect uses the class’ SctpSocket instance to prepare the init messages(see SCTP handshake in Subsection 6.1.1). In the end, a SctpTimeoutThread is started,which cancels the method and calls d.reject() if the connection attempt does not succeedin time.

public Promise<SctpChannelFacade, Exception, Void> connect(final

InetSocketAddress remote) {

final Deferred<SctpChannelFacade, Exception, Void> d = new

DeferredObject<>();

final CountDownLatch countDown = new

CountDownLatch(NUMBER_OF_CONNECT_TASKS);

if (!Sctp.isInitialized()) {

d.reject(new SctpInitException("Sctp is currently not initialized! Try

init it with SctpUtils.init(...)"));

return d;

}

try {

NotificationListener l = addNotificationListener(d, countDown);

SctpChannel.this.setNotificationListener(l);

mapper.register(remote, SctpChannel.this);

LOG.debug("try connect to {}/{}, ",

remote.getAddress().getHostAddress(), remote.getPort());

so.connectNative(remote.getPort());

} catch (IOException e) {

LOG.error("Could not connect via SCTP! Cause: " + e.getMessage(), e);


mapper.unregister(remote);

d.reject(e);

}

SctpUtils.getThreadPoolExecutor()

.execute(new SctpTimeoutThread(d, CONNECT_TIMEOUT_SECONDS,

TimeUnit.SECONDS, countDown));

return d.promise();

}

containsSctpSocket() is a method needed from SctpMapper. The method checks if thesuggested SctpSocket is assigned to the current SctpChannel object. listen() is theimplementation of the listen service primitive from [40]. The method makes the corre-sponding SctpSocket listen to incoming connections. onConnIn() forwards all receivedSCTP packets from the NetworkLink to the corresponding SctpSocket. Afterwards, thepackets are encoded via usrsctp. The method setLink() defines the NetworkLink, whichis used to encapsulate the SCTP association with a UDP header. Additionally, via thisNetworkLink, also the incoming SCTP packets are decoded.

6.2.3 SctpChannelBuilder

SctpChannelBuilder is a class, which is implemented according to the builder pattern[10]. The class helps instantiating SctpChannel objects. The most important method ofthis class is build(). This method triggers the creation of the SctpChannel object.

6.2.4 SctpMapper

To ensure the reply service primitive, sctp4nat needs to cache information about theremote endpoint as well as the local SCTP representation. SctpMapper is responsiblefor caching this information. It contains a ConcurrentHashMap, which maps an Inet-

SocketAddress (the remote endpoint) to a SctpChannel (the local endpoint). Methodregister() creates such a mapping, unregister() removes it. The method locate() is usedto find a specific mapping either via remote endpoint information (IP address and port)or via a SctpSocket instance. shutdown() causes the SctpMapper instance to close ev-ery remaining active SctpChannel. Afterwards, the ConcurrentHashMap containing thecached information is cleared.

6.2.5 SctpPorts

The SctpPorts class cares about the port assignement of usrsctp. It keeps track of all theassigned ports and caches the information in a ConcurrentHashMap called portMap. Apartfrom storing ports via putPort() and releasing port via removePort(), the class providesmethods to check if a port is already in use (isUsedPort()). Additionally, SctpPorts makes

6.3. PACKAGE NET.SCTPNAT.CONNECTION 37

the creation of random free ports available with its method called generateDynPort(). Theuser then will get a port from a defined port range (between 49152 and 65535), which isnot used by usrsctp, yet. The shutdown() method is responsible for clearing the contentsof the map and should only be called after usrsctp.finish() is executed.SctpPorts is asingleton [10], because there should only exist one single instance, which keeps track ofthe port information.

6.2.6 SctpTimeoutThread

SctpTimeoutThread is a class extended from java.lang.Thread. Thus, it contains amethod called run(), which is executed on command. The class purpose is to provideSctpChannel.connect() a timeout limit. SctpTimeoutThread will notify the Promise

object either if an error occured while the association setup or if the setup took too long.In the latter case a TimeoutException will be thrown and the Promise object returns anerror.

6.3 Package net.sctpnat.connection

The connection package consists of four classes and one interface. Namely the classesare SctpConnection, SctpDefaultStreamConfig, UdpClientLink and UdpServerLink.The interface is called NetworkLink. The package provides the sctp4nat project withimplementations of NetworkLink (see UdpServerLink and UdpClientLink) as well aswith convenience methods for creating SCTP associations (see SctpConnection and Sct-

pDefaultStreamConfig). The package with its classes and associations is visualized inFigure 6.3.

Figure 6.3: The net.sctp4nat.connection Package


6.3.1 SctpConnection

SctpConnection is a class, which combines the builder pattern [10] with the possibilityto automatically connect to a remote SCTP endpoint. Additionally, if an error occurs,the class will release all assigned parameters (e.g. SctpMapper, SctpPorts). Therefore,the class contains three crucial methods. First, the build() method, which creates aSctpConnection instance. Second, connect() will cause the underlying SctpChannel tocall its connect() method. Thus, the SCTP handshake will be started.

6.3.2 SctpDefaultStreamConfig

SctpDefaultStreamConfig is a convenience class, which is used for sending or definingthe default SctpDataCallback in sctp4nat. In future, the class can be extented withadditional variables or parameters for the sake of configuring the association.

6.3.3 NetworkLink

NetworkLink is an interface, which provides two methods. The first method onConnOut()is used for sending SCTP packets. The method is called by the usrsctp counterpart, once auser of sctp4nat sends packets via SCTP. Each SctpSocket must contain a NetworkLink

to send packets. UdpServerLink and UdpClientLink are classes, which implement thisinterface. The close() method provides the implementor of the NetworkLink interface toclose the link if an error occured. It initiates the shutdown of the NetworkLink.

6.3.4 UdpClientLink

UdpClientLink implements the NetworkLink interface. Therefore it implements themethods onConnOut() and close(). The first of these methods is responsible for sendingthe outgoing SCTP packet to the remote endpoing. For this cause UdpClientLink willcreate a UDP packet and add the SCTP packet as payload to it. Afterwards it sends thepacket to the remote endpoint. The process is visualized in code snippet below.

@Override

public void onConnOut(final SctpChannelFacade facade, final byte[] data,

final int tos) throws IOException, NotFoundException {

DatagramPacket packet = new DatagramPacket(data, data.length,

this.remote.getAddress(), this.remote.getPort());

udpSocket.send(packet);

}

The close() method causes the class to close its contained DatagramSocket. Therefore,the link will not be usable, once close() was called. Further, UdpClientLink also has amethod called receive(). This method is started as soon as the class is instanciated and

6.3. PACKAGE NET.SCTPNAT.CONNECTION 39

runs in its own Thread. receive() contains a while-loop which repetitively checks the class’udpSocket receive buffer. Once a new packet arrives, it is encoded and the decoded packetwill be forwarded to the usrsctp counterpart via onConnIn(). The method is shown in thecode snippet below. It is important to know, that the UdpClientLink knows the remoteendpoint.

private void receive(final InetSocketAddress remote, final SctpChannel so) {

SctpUtils.getThreadPoolExecutor().execute(new Runnable() {

public void run() {

try {

byte[] buff = new byte[2048];

DatagramPacket p = new DatagramPacket(buff, 2048);

while (!isShutdown) {

udpSocket.receive(p);

so.onConnIn(p.getData(), p.getOffset(), p.getLength());

}


LOG.error(e.getMessage());

}

LOG.debug(

"Link shutdown, closing udp connection to " +

remote.getHostString() + ":" + remote.getPort());

}

});

}

6.3.5 UdpServerLink

UdpServerLink holds the DatagramSocket, which is used for all incoming connectionattempts. Therefore, the class does not know a remote endpoint, since it is usually thepoint, where the first contact happens. Alike UdpClientLink, UdpServerLink containsthe methods receive(), onConnOut() and close(). close() and onConnOut() work similarto the respective methods in UdpClientLink. But receive() behaves different. This pro-cess is visualized in the code snippet below. If a new packet arrives over the containedDatagramSocket, the method first checks, if the remote endpoint is already known. Ifif is known, the packet is decoded and forwarded to the native counterpart (usrsctp) viaonConnIn(). If not, this means, that an new SCTP endpoint wants to connect to thisSCTP endpoint.

private void receive(final SctpMapper mapper, final InetAddress localAddress,

final int localPort, final SctpDataCallback cb) {

SctpUtils.getThreadPoolExecutor().execute(new Runnable() {

@Override

public void run() {

SctpChannel so = null;


while (!isShutdown) {

byte[] buff = new byte[2048];

DatagramPacket p = new DatagramPacket(buff, 2048);

try {

udpSocket.receive(p);

InetSocketAddress remote = new

InetSocketAddress(p.getAddress(),

p.getPort());

so = SctpMapper.locate(p.getAddress().getHostAddress(),

p.getPort());

if (so == null) {

LOG.info("New INIT arrived. Now starting the setupSocket()

process...");

so = setupSocket(localAddress, localPort, p.getAddress(),

p.getPort(), cb, mapper);

mapper.register(remote, so);

LOG.info("onConnIn() Called with IP and port /" +

p.getAddress().getHostAddress() + ":"

+ p.getPort());


} else {


}


if (!isShutdown) {

LOG.error("Error while receiving packet in

UDPClientLink.class!", e);

} else {

LOG.debug("receive aborted because of shutdown!");

}

} catch (SctpInitException e) {

LOG.error("Sctp is currently not initialized! Try init it with

SctpUtils.init(...)", e);

}

}

LOG.debug("Link shutdown, stop listening, closing udp connection");

}

});

}

For this cause, a new SctpChannel is needed to deal with this endpoint. Method setup-Socket() provides this functionality (see code snippet below). This method creates a newSctpChannel (including the SctpSocket and makes it listen to incoming connections.Once the SctpChannel is returned by setupSocket(), the SctpChannel gets registered onSctpMapper. After the registration, onConnIn() is called to forward the INIT messagefrom the remote endpoint to the newly created SctpChannel.

6.4. PACKAGE NET.SCTPNAT.UTIL 41

private SctpChannel setupSocket(final InetAddress localAddress, final int

localPort, final InetAddress remoteAddress, final int remotePort, final

SctpDataCallback cb, final SctpMapper mapper) throws SctpInitException

{

SctpChannel so = new SctpChannelBuilder().

networkLink(UdpServerLink.this).

localSctpPort(localPort).

sctpDataCallBack(cb).

remoteAddress(remoteAddress).

remotePort(remotePort).

mapper(mapper).

build();

LOG.info("new SctpChannel object created --> " + so.toString());

so.listen();

return so;

}- why test?

6.4 Package net.sctpnat.util

The util package provides the sctp4nat library with necessary services, which cannot beassigned to any other package. It contains of two classes, which are SctpInitException

and SctpUtils.

6.4.1 SctpInitException

SctpInitException is an Exception, which is thrown, if the user of sctp4nat tries toinitialize usrsctp twice or more. The usrsctp library must not be initialized more thanonce. Otherwise, sctp4nat would not know which usrsctp library instance it has to call,which results in serious errors in JNI.

6.4.2 SctpUtils

SctpUtils holds methods to initialize and shutdown the sctp4nat library. Additionally, itholds several, for sctp4nat important, constants and variables. To initialize sctp4nat, theclass provides the method init(). This method is visualized in the code snippet below. Themethod does three things. It initializes the usersctp library, it defines the default callbackfor SctpDataCallbacks and it creates a UdpServerLink to be able to be contacted fromthe network. If an error occurs within the method, it throws an exception.

public static synchronized void init(final InetAddress localAddr, final int

localSctpPort, SctpDataCallback cb)


throws SocketException, SctpInitException {

if (Sctp.isInitialized()) {

throw new SctpInitException("Sctp is already initialized. You should

not initialize it twice!");

} else {

Sctp.getInstance().init();

}

if (cb == null) {

cb = new SctpDefaultStreamConfig().grealWorldetCb();

}

if (localAddr == null) {

throw new SctpInitException("ServerAddress was null! Can’t init sctp

without a valid InetSocketAddress!");

} else if (!checkFreePort(localSctpPort) || !checkRange(localSctpPort)) {

link = new UdpServerLink(mapper, localAddr, cb);

} else {

link = new UdpServerLink(mapper, localAddr, localSctpPort, cb);

}

if (SctpMapper.isShutdown()) {

LOG.warn("You are overwriting isShutdown in SctpMapper! This probably

causes serious inconsistencies!");

}

SctpMapper.setShutdown(false);

}

The method shutdownAll() shuts down the whole sctp4nat library including the usrsctpcounterpart. shutdownAll() returns a Promise object and therefore is non-blocking. Itdisconnects and closes all SctpChannels, NetworkLinks and SctpSockets. Additionally itclears the cached remote endpoint information on SctpMapper. Also, shutdownAll() willclear the assigned ports on SctpPorts. At last, the method frees all allocated resourceson the usrsctp counterpart by calling Sctp.finish().

6.5 usrsctp Adjustments

The native counterpart to sctp4nat consists of two files written in C. Namely, net sctp4nat Sctp.cand net sctp4nat Sctp.h. Both files including all methods had to be renamed to work withJNI in sctp4nat properly. Both files, originally written for the sctp4j library, had to beextended to support sctp4nat. First, many more SCTP EVENT TYPES are now in-cluded. This is needed, because sctp4nat reacts to these events via SctpNotification.An example for such an event is SCTP ASSOC CHANGE. Once usrsctp completed theinitial handshake, it emits the SCTP ASSOC CHANGE event. This event is forwardedvia JNI and catched by the callback called SctpNotification. This way, the library is

6.6. JUNIT TESTING OF SCTP4NAT 43

notified, once the handshake is completed. Second, the shutdown() method had to beadded to the JNI and the usrsctp interface. This method was not included in the orig-inal implementation. Third, some parameters were adjusted (e.g. buffer size) and somedetected bugs were fixed.

6.6 Junit Testing Of sctp4nat

To test the implementation of the sctp4nat library, 12 Java Unit (JUnit) were written.Overall, the test coverage according to the Eclipse Java EE Coverage tool is at 60.9%.The reason, why this number is below the required 80% is because it is not possible to testJNI methods properly in JUnit. Additionally, the affected classes with low test coverageprovided by Libjitsi. It is assumed, that they are already tested by the sctp4j project,since this project is implemented in Jitsi. Because the net.sctp4nat.origin package isresponsible for 27.8% of the code of sctp4nat, it distorts the test coverage [9]. The totalamount of instructions in packages net.sctp4nat.core, net.sctp4nat.connection andnet.sctp4nat.util is 2462. The number of instructions covered by the JUnit testsof sctp4nat is 2014. Thus, the purged test coverage results in 81.8%. Therefore, therequirement of 80% test coverage is fulfilled.

6.7 Integration Into TomP2P

During the term of this master thesis, the decision was to integrate sctp4nat into TomP2P.For this reason, a prototype of how the future communication of TomP2P should beimplemented into the P2P framework. To achieve this requirement, the decision wasmade to implement the library into the ChannelServer and ChannelClient class. Thefollowing sections document the changes made in TomP2P.

Figure 6.4 shows the integration concept of sctp4nat in three steps. Step one, Peer Acreates a SCTP endpoint and contacts the target peer B via UDP. Peer A signals in itsinitial message, that it likes to establish a SCTP connection. Thus, instead of replyingvia UDP, Peer B creates a SCTP endpoint and tries to connect to PeerA via SCTP overUDP. This is visualized in step two. After the connection was established, Peer A is ableto send messages to Peer B over SCTP via UDP. The reason why Peer B initiates theSCTP connection instead of Peer A is that the UDP reply message from Peer B can beomitted. This means that for a SCTP association setup, only two and a half RTT’s haveto be made instead of three RTT’s. This saves time and resources.

6.7.1 ChannelServer

Since the decision was, not to implement UdpServerLink and UDPClientLink, the re-spective NetworkLinks had to be implemented elsewhere. The ChannelServer class fromTomP2P is responsible for all incoming network traffic. It dispatches all received packets


Figure 6.4: The integration concept how TomP2P should establish SCTP via UDP con-nections

and forwards them to the responsible DispatchHandler. Thus, the class represents theequivalent of UdpServerLink. If a new packet arrives in the ChannelServer, it checksif the packet contains SCTP payload. TomP2P adds a flag to each SCTP packet, whichmarks a packet, which was sent by SCTP over UDP. If the packet containes SCTP payload,it is forwarded to the respective usrsctp socket.

Additionally to the forwarding of SCTP messages, ChannelServer is also responsible forestablishing SCTP via UDP connections. For this reason, method connectSCTP() wasimplemented. The method creates a SctpChannel and tries to connect to the targetendpoint. The process of creating and connecting is analogous to the process of con-nect() from SctpConnection (see Subsection 6.3.1). Additionally to the creation of theSctpChannel object, an own implementation of NetworkLink is specified. This imple-mentation includes the addition of a bit to the whole SCTP packet. This bit signals, if apacket containes SCTP content or not.

public static Promise<SctpChannelFacade, Exception, Void> connectSCTP(final

ConcurrentCacheMap<InetSocketAddress, SctpChannel> openConnections,

final DatagramChannel datagramChannel, final InetSocketAddress

remote, Message m)

throws Exception {

final Promise<SctpChannelFacade, Exception, Void> p;

if(m.isKeepAlive() && m.isRequest() && m.sctp()) {

LOG.debug("setup SCTP connection: {}", m);

int localSctpPort =

ChannelUtils.localSctpPort(IP.fromInet4Address(remote.getAddress()),

remote.getPort());

SctpChannel sctpChannel = new SctpChannelBuilder()

.remoteAddress(remote.getAddress())

.remotePort(remote.getPort())

6.7. INTEGRATION INTO TOMP2P 45

.mapper(SctpUtils.getMapper())

.localSctpPort(localSctpPort).build();

LOG.debug("local sctp port: {}", localSctpPort);

openConnections.put(remote, sctpChannel);

sctpChannel.setLink(new NetworkLink() {

@Override

public void onConnOut(final SctpChannelFacade so, final byte[]

packet, final int tos) throws IOException, NotFoundException {

try {

ByteBuffer buf = ByteBuffer.allocate(packet.length+1);

buf.put((byte)(1 << 6));

buf.put(packet);

buf.flip();

LOG.debug("server out SCTP: "+buf.remaining() + " to " +

remote);

datagramChannel.send(buf, remote);

} catch (Throwable t) {

t.printStackTrace();

LOG.error("cannot send",t);

}

}

@Override

public void close() {

//do nothing, server keeps its connection open

//TODO

}

});

p = sctpChannel.connect(remote);

} else {

p = null;

}

return p;

}

private void send(final InetSocketAddress remote, Message m2)

throws InvalidKeyException, SignatureException, IOException {

LOG.debug("peer isVerified: {}", m2.isVerified());

CompositeByteBuf buf2 = Unpooled.compositeBuffer();

Encoder encoder = new Encoder(new DSASignatureFactory());

encoder.write(buf2, m2, null);

packetCounterSend.incrementAndGet();

LOG.debug("server out UDP:"+ByteBufUtil.prettyHexDump(buf2) + " to " +

remote);


datagramChannel.send(ChannelUtils.convert(buf2), remote);

}

6.7.2 ChannelClient

ChannelClient can be considered a combination of UdpServerLink (see Subsection 6.3.4)and SctpChannelBuilder (see Subsection 6.2.3. It has the ability to create SctpChan-

nels by calling createSCTPSocket() and the ability to send and receive SCTP via UDPmessages. Worth mentioning is also, that ChannelClient does not initiate an SCTPconnection. Messages, which need to be transmitted via SCTP over UDP will be cacheduntil the corresponding SCTP via UDP endpoint has established the connection.

Chapter 7

Evaluation

This thesis requires a real-world test of the solution approach suggested in Section 2.5. Thetest must reveal, wether or not sctp4nat is able to run via Internet and therefore if it is ableto overcome NAT boundaries. Given the thesis requirements, the test scenario visualizedin Figure 7.1 was defined. To investigate the behaviour of sctp4nat in the Internet, twopeers are required. These peers are visualized as Peer A and Peer B. Further, both peersneed to use a NAT to demonstrate the NAT friendliness of sctp4nat (and therefore SCTPvia UDP). Also, both peers need to be located as in different places (at least in twodifferent cities). These requirements resulted in the test scenario defined by Section 7.1.Section 7.2 shows the test environment and the circumstances, in which the test wasrunning. Section 7.3 shows and discusses the results of the tests made.

7.1 Test Scenario

The test scenario for sctp4nat consists of two Peers (A and B). Both peers are using aport-preserving Port Restricted Cone NAT. It is assumed, that Peer A and Peer B knowthe endpoint information (IP address and port) of each other. At first, Peer B beginsto send messages (see sendDummy()) to peer A’s endpoint. This creates the requiredNAT mapping on the NAT of peer B. Afterwards, Peer A initiates the establishment ofthe SCTP via UDP association. Because there is a valid NAT mapping, Peer A’s INITreaches Peer B and causes it to answer back with INIT ACK. This INIT ACK messageis able to reach Peer A, because the sending of the INIT message caused Peer A’s NATto create the required mapping. From this point on, the peers are able to finish thehandshake. Once the association is established, Peer A is able to send messages to PeerB and vice versa.

7.2 Test Environment

For the test, the two Linux machines were used. One of them was one of the machinesmentioned in Subsection 2.5.3. The other machine was a Fujitsu Server (Intel Core 2 Duo

47

48 CHAPTER 7. EVALUATION

Figure 7.1: Test scenario used for the real-world test of sctp4nat

CPU T9400 [23] 2.53GHz, 8GB of RAM). Each of the machines ran a test application,which is described more closely in Subsection 7.2.1. The machine in Lucerne, was using aAVM FritzBox! 7490 NAT device. The machine in Zurich was located behind several dif-ferent layers of NAT, some of which were Port Restricted Cone NAT with port-preserving.

7.2.1 Test Application

To test the sctp4nat library in the Internet, a test application was developed. The appli-cation is written in Java and using the sctp4nat library. The application requires bothusers (Peer A and Peer B) to know the endpoint information of the corresponding peer.There are two modes, in which the application is able to run. Namely, server mode andclient mode. Considering Figure 7.1 the client mode is run by Peer A and the server modeis run by Peer B.

The following sequence shows the setup of the server. At first, the arguments (endpointinformation) are casted into the needed variables. Afterwards, the sctp4nat library isinitialized by calling SctpUtils.init(sourceIP, sourcePort, cb. Once the library is initial-ized, a new Thread is started, which sends dummy packets to the corresponding peer inorder to punch a hole into the NAT (create a NAT mapping). The sending of the dummypackets is done by calling the Linux terminal and using sendIP (see Subsubsection 2.5.2).

public static void main(String[] args)

throws UnknownHostException, SocketException, NumberFormatException,

SctpInitException {

LOG.debug("Setup of SampleHolePServer started.");

if (args.length < 4) {

7.2. TEST ENVIRONMENT 49

LOG.error("Not enough arguments! System exiting application...");

System.exit(1);

}

castArgs(args);

LOG.debug("initiating usrsctp and setup of SctpMapper and

UdpServerLink");

SctpUtils.init(sourceIP, sourcePort, cb);

new Thread(holePuncher).start();

LOG.debug("Setup of SampleHolePServer finished");

}

Starting the test application in client mode is similar to starting the application in servermode. The following sequence shows the client mode. But after the casting of the argu-ments delivered by the application input, the client creates its own SctpChannel to beable to connect to the server. Afterwards, it tries to connect to the server via the knownendpoint information. Once the channel is connected, it sends a message containing ”HelloWorld” to the server.

public static void main(String[] args) throws IOException, SctpInitException {

LOG.debug("Setup of SampleHolePClient started.");

if (args.length < 4) {

LOG.error("Not enough arguments! System exiting application...");

System.exit(1);

}

castArgs(args);

LOG.debug("initiating usrsctp and setup of SctpMapper and

UdpServerLink");

SctpUtils.init(sourceIP, sourcePort + 1, cb);

castArgs(args);

SctpChannel so = new

SctpChannelBuilder().localSctpPort(sourcePort).remoteAddress(destinationIP)

.remotePort(destinationPort).sctpDataCallBack(cb).mapper(SctpUtils.getMapper()).build();

NetworkLink link = new UdpClientLink(new InetSocketAddress(sourceIP,

sourcePort),

new InetSocketAddress(destinationIP, destinationPort), so);

so.setLink(link);

Promise<SctpChannelFacade, Exception, Void> p = so

.connect(new InetSocketAddress(destinationIP, destinationPort));


p.done(new DoneCallback<SctpChannelFacade>() {

@Override

public void onDone(SctpChannelFacade result) {

LOG.debug("connected to {}/{}", destinationIP, destinationPort);

result.send("Hello World!".getBytes(), false, 0, 0);

}

});

p.fail(new FailCallback<Exception>() {

@Override

public void onFail(Exception result) {

LOG.error(result.getMessage());

result.printStackTrace();

System.exit(1);

}

});

LOG.debug("Setup of SampleHolePClient finished");

}

Both, client and the server contain the same SctpDataCallback (see the following codelisting). Thus, the ”Hello World” message is sent back and fourth between the client andthe server. Also, the application uses retransmissions and congestion control mechanisms.This allows the tester to test the consistent delivery of SCTP messages via sctp4nat.

protected static final SctpDataCallback cb = new SctpDataCallback() {

@Override

public void onSctpPacket(byte[] data, int sid, int ssn, int tsn, long

ppid, int context, int flags,

SctpChannelFacade facade) {

connected = true;

LOG.debug("onSctpPacket() called with data {}", new String(data,

StandardCharsets.UTF_8));

facade.send(data, false, sid, (int) ppid);

}

};

7.2.2 Test Locations

As locations for the tests, Lucerne (Staldenhoehe 34) and Zurich (Binzmuehlestrasse 14)were chosen. The exact position of the computers running the test application is shownin Figure 7.2. The coordinates of both computerst were the following:

7.3. TEST RESULTS 51

• Lucerne, 47.06301 latitude, 8.27352 longitude

• Zurich, 47.41426 latitude, 8.54964 longitude

These two locations are 44.3 kilometers away from each other. Linux traceroute fromboth locations resulted in 15 hops between the location in Lucerne and the one in Zurich.

©swisstopo,public.geo.admin.ch

www.geo.admin.ch ist ein Portal zur Einsicht von geolokalisierten Informationen, Daten und Diensten, die von öffentlichen Einrichtungen zur Verfügung gestellt werdenHaftung: Obwohl die Bundesbehörden mit aller Sorgfalt auf die Richtigkeit der veröffentlichten Informationen achten, kann hinsichtlich der inhaltlichen Richtigkeit, Genauigkeit, Aktualität, Zuverlässigkeit undVollständigkeit dieser Informationen keine Gewährleistung übernommen werden.Copyright, Bundesbehörden der Schweizerischen Eidgenossenschaft. http://www.disclaimer.admin.ch

6km420Massstab 1: 300,000

Gedruckt am 10.12.2017 13:00https://s.geo.admin.ch/776bde8253

Figure 7.2: Test locations used [3]

7.3 Test Results

For the Internet test of sctp4nat, two seperate tests were made. The first test (see inSubsection 7.3.1) shows if the library is able to work in the Internet. The second test(see in Subsection 7.3.2) reveals if sctp4nat is able to work in the Internet consistently.The generated test data can be found in the CD content of this bachelor thesis in foldersConsistency Test and Internet Test.

7.3.1 Internet Test Results

Table 7.1 shows the test results. The test ran on the 7th of December 2017 at 17:58:38.Both endpoints were able to connect to each other. The test ran for 3 minutes and 20


seconds. It was stopped manually. In total, 34048 packets were transmitted between bothlocations. The results show, that 100% of the ”Hello World” messages were delivered tothe respective peer. Thus, the results show, that SCTP via UDP with sctp4nat works inthe Internet between the two chosen endpoints. Additionally, the RTT’s of both endpointsshow, that the latency requirement for real-time conferencing is fulfilled.

Packets sent Packets received Average RTTPeer A 17283 16765 14,56 millisecondsPeer B 16765 17283 15,01 milliseconds

Table 7.1: Test results from the Internet test of sctp4nat.

7.3.2 Consistency Test Results

This test ran on the 10th of December from 12:49:25 o’clock until 23:18:51. The maindifference between this test and the test from the previous section (see Section 7.3) is thatthe test was repeated 100 times. Also, one test run consisted of sending 1000 SCTP viaUDP packets in each direction. For this reason the test application had to be slightlyadjusted. After exchanging the defined number of packets, the application was shutdown.The interval between two test runs was 300 seconds. This waiting time was necessary toensure the destruction of created NAT mappings on the affected NAT devices betweenthe test locations. To be able to start and shutdown the test application two Linux Bashscripts were written (see in Appendix C). The test results are shown in Table 7.2.

Successfulassociation

setupratio

Hello Worldpackets

sent

Hello Worldpacketsreceived

Totalnumber

ofPackets

sent

Totalnumber

ofPacketsreceived

Peer A 100% 100’000 99’900 105’141 105’049Peer B 100% 99’900 100’000 105’049 105’141

Table 7.2: Test results from the consistency test of sctp4nat.

The test results show, that 100% of the connection attempts were successful. Also, 100%of the sent packets were received by the respective counterpart. The reason why thereare only 99900 packets sent by Peer B is because Peer B’s shutdown condition was boundto the number of received packets. Thus, Peer B did not send the 1000th packet for 100test runs, which results in 100 packets less than 100000. Nevertheless, the test is stillconsidered to be valid.

Considering the test results from both test runs (Internet test and Consistency test) theresults point out, that under the given test environment conditions, sctp4nat is able torun in the Internet consistently.

Chapter 8

Summary, Conclusion, And FutureWork

In Chapter 2, the thesis investigated on three well-known transport protocols. Namely,TCP (and TCP Fast Open), UDP and SCTP. It summarizes their features, advantagesand disadvantages. The thesis applies the protocol to the streaming requirements ofstored media streaming, live media streaming and real-time conferencing. For storedmedia streaming, TCP and SCTP are considered better options than UDP, because theyexperience no data loss while delay and larger buffers do not matter that much. UDP isconsidered best for live media streaming since it is better suited for multicasting than TCPand SCTP. The latter two protocols consume proportionally more resources than UDPif more consumers are added. SCTP is well-suited for Real-time conferencing, because itallows the user to adjust the protocol parameters to its need. For example, the user isable to use flow control on demand [37].

Also, the thesis analyized the NAT traversal behaviour of TCP Fast Open, SCTP andUDP. The behaviour was tested on Port Restricted Cone NAT with port-preserving. Thetest showed, that UDP and TCP are accepted by Iptables, AVM FritzBox! and TP-Link(OpenWRT) NAT devices while SCTP traffic is completely ignored. Thus, the test showedthat SCTP does not work in the Internet because it cannot be considered NAT friendly.But since SCTP works well with stored media streaming and real-time conferencing, thethesis suggested the use of SCTP encapsulated via UDP. In short, this means that eachSCTP message is given a UDP header on top. This way, SCTP traffic is treated as UDPtraffic, which is NAT friendly. The consequences are that the SCTP packets need tobe packed twice, which is a time and resource consuming operation. Also, the solutionapproach makes the use of the protocol more complex [41].

This thesis introduces sctp4nat. sctp4nat is a Java library which enables the user touse SCTP encapsulated via UDP. The reason why an own implementation was neededis because there was no other Java library available, which implemented the six serviceprimitives with support for UDP encapsulation at the time the thesis was written. Thelibrary had to be written in Java, since the use of the solution needed to be implementedinto TomP2P. In Chapter 4, the thesis requirements deducted from the solution approachare stated. This thesis fulfilled all must-have and should-have requirements. The only

53

54 CHAPTER 8. SUMMARY, CONCLUSION, AND FUTURE WORK

nice-to-have requirement was not implemented. The decision was to let the user split andcombine packets larger than 1 MB. The reason for that was that different environmentssupport different MTU’s. Thus, if the user is able to decide the MTU size himself, theuser is able to use the MTU boundaries much more efficiently. Chapters 5 and 6 describehow the sctp4nat library was designed, implemented and integrated into TomP2P. Theresults can be seen in the Internet on the respective Github repositories (see [31] and [43]).

In Chapter 7 the thesis tested the implemented solution approach in the real world. Forthis reason a test application as developed. The test application contained a mechanismto force NAT mappings on the NAT used by the user of the application. After punchingholes through the respective NAT, both users of sctp4nat would be able to connect toeach other and send messages through the Internet. The test showed, that sctp4nat isable to run in the Internet with little delay. Also, the 100% successful connections showthat the solution approach is able to run consistently over time.

8.1 Conclusion

Considering the theoretical background in Chapter 2, the tests made in Section 2.5 andChapter 7 as well as the design, implementation and integration of sctp4nat (see Chap-ters 5 and 6), the following three conclusions are made:

First, deducted from the test described in Section 2.5, it can be concluded, that withcommon NAT devices, SCTP does not work in the Internet. The main reason for thisis that SCTP as a protocol is not supported by most NAT devices. Furthermore, untilNAT vendors decide to support SCTP in their devices, SCTP will remain unusable in theInternet.

Second, the use of UDP headers makes it possible to run SCTP in the Internet withcommon NAT devices. Since UDP headers are recognized by NAT devices and onlycontain a small header compared to TCP they are also a valid encapsulation option forother transport layer protocols apart from SCTP.

Third, the implementation of the suggested protocol fullfills all the requirements for real-time conferencing as well as stored media streaming. Also, the implementation of theprotocol (sctp4nat) was able to traverse NAT devices. A real world test showed, thattextbfthe implementation also worked successfully in the Internet under the given testconditions. The suggested protocol was integrated into TomP2P and replaced the use ofTCP for TomP2P.

8.2 Limitations

This thesis scope is limited to the use of SCTP and SCTP encapsulated via UDP in theInternet. Two of the three, namely delay and data loss, core requirements of the protocol,which was required to be implemented into TomP2P were only compared on a theoretical

8.3. FUTURE WORK 55

base. Thus, this thesis cannot claim that the use of SCTP, with or without encapsulationvia UDP, is more efficient or more reliable than TCP or UDP.

By putting a UDP header on top of SCTP, SCTP as a protocol gained the NAT friend-liness features of UDP. NAT friendly means, that the protocol is able to overcome PortRestricted Cone NAT with port-preserving. Deducted from this experience, this thesisshows, that the use of UDP headers for a transport layer protocol makes the protocolNAT friendly. This is not the first paper stating such a claim, but this thesis confirms it[41].

This thesis analyzed the NAT friendliness of SCTP and TCP Fast Open. Section 2.5pointed out, that both protocols are not considered NAT friendly. Although SCTP viaUDP is considered NAT friendly, the original SCTP (via UDP) it is not. Nevertheless,since many implementations omit the use of Multihoming (see Subsection 5.1.1), SCTPvia UDP can be considered NAT friendly.

Although the sctp4nat test was successful, the test does not guarantee, that real-timeconferencing is supported in all cases. But the low latency values (see RTT times onTable 7.1) point out that it is possible. To test real-time conferencing, TomP2P wouldhave to offer a Skype-like application, which it does not contain at the moment.

8.3 Future Work

In future sctp4nat is suggested to add support for non-Linux based systems. Specifically,the usrsctp library needs to be cross-compiled for Windows and Macintosh based systems.This feature would add the expected platform independence to the Java library.

For future work, TomP2P could add support for Hole Punching with SCTP via UDP. Thesteps needed for the further implementation are analogous to [46]. Hole Punching wouldgive TomP2P the opportunity to run in the Internet across many NAT devices. Also, itis suggested for TomP2P to implement a library for real-time conferencing. Once such alibrary is implemented, SCTP over UDP could be tested how it performs in a real-timeconferencing context.

QUIC (see Section 3.2), a protocol based on UDP claims also to combine the featuresof UDP and TCP similar to SCTP. It claims to dramatically reduce the connection es-tablishment time and to support congestion and flow control. At the time, this thesiswas written there was no Java implementation of QUIC available. But in future, it issuggested to implement QUIC into TomP2P to compare its performance and resourceconsumption with SCTP [12].

Another suggestion for future work would be to implement SCTP via UDP fully in Java.This means, that such an implementation would require the whole SCTP specificationneeded to be implemented in a way, that it supports SCPT encapsulation via UDP. Thiswould remove the need for native libraries such as usrsctp [45].

56 CHAPTER 8. SUMMARY, CONCLUSION, AND FUTURE WORK

Bibliography

[1] Abley, J. et Al.: IPv4 Multihoming Practices and Limitations. RFC 4116, RFC Edi-tor, https://tools.ietf.org/html/rfc4116, July 2005

[2] Allegro Software Development Corporation et Al.: UPnP Device Architecture 1.0.UPnP Forum, October 2008

[3] Bundesamt fuer Landestopografie Webseite: Karten der Schweiz - SchweizerischeEidgenossenschaft. Available at: https://map.geo.admin.ch, December 2017

[4] Canepa, G.: 10 Tom Most Polular Linux Distributions of 2016. Tecmint.com Arti-cle, https://www.tecmint.com/top-best-linux-distributions-2016/, January2017

[5] Caro Armando, L. et Al.: SCTP: A Proposed Standard for Robust Internet DataTransport. IEEE Computer Journal, volume 36, number 11, pp 56-63, November2003

[6] Cheng, Y. et Al.: TCP Fast Open. RFC 7413, RFC Editor, https://tools.ietf.org/html/rfc7413, December 2014

[7] Cheshire, S. Krochmal, M.: NAT Port Mapping Protocol (NAT-PmP).RFC Draft Version 13, RFC Editor, https://tools.ietf.org/html/

draft-ietf-rtcweb-data-channel-13, January 2015

[8] DARPA Internet Program: Transmission Control Protocol RFC 793, RFC Editor,https://tools.ietf.org/html/rfc793, September 1981

[9] Eclipse Foundation Website: Download Eclipse Oxygen. Available at:https://www.eclipse.org/downloads/download.php?file=/oomph/epp/

oxygen/R/eclipse-inst-linux64.tar.gz, December 2017

[10] Gamma, E. et Al.: Design Patterns: Elements of Reusable Object-Oriented Software.,Addison-Wesley, ISBN: 0201633612, 1994

[11] Github Website: Github - Built for Developers. Available at: https://github.com/,December 2017

[12] Hamilton, R. et Al.: QUIC: A UDP-Based Secure and Reliable Trans-port for HTTP/2. Internet-Draft, RFC Editor, https://tools.ietf.org/html/

draft-hamilton-early-deployment-quic-00#section-1, July 2016

57

58 BIBLIOGRAPHY

[13] Jesup, R., Loreto, S., Tuexen, M.: NAT Port Mapping Protocol (NAT-PmP). RFC6556, RFC Editor, http://www.rfc-editor.org/rfc/rfc6556, April 2013

[14] jitsi Website: The most innovative opensource video conferencing community. Period.Available at: https://jitsi.org/, November 2017

[15] Kazuhiro T., Akihiro, S. and Shigeki, G.: Extended UDP Multiple Hole PunchingMehtod to Traverse Large Scale NATs. In proceedings of the Asia-Pacific AdvancedNetwork 2010, pp. 30-36, 2010

[16] Kirk, P.: The Annotated Gnutella Protocol Specification v0.4. Developer Forum, 1.6edition, 2003

[17] Microsoft Corporation: Sicherheitsanfaelligkeit in Universellem Plug n’Play kannRemotecodeausfuehrung ermoeglichen (931261). Technet Article, April 2007

[18] Min, S. h., Holliday, J., Cho, D. s.: Optimal Super-peer Selection for Large-scaleP2P System., International Conference on Hybrid Information Technology, Inpro-ceeding, pp.588-593, Cheju Island, Available at: http://ieeexplore.ieee.org/

stamp/stamp.jsp?tp=&arnumber=4021271&isnumber=4021174, 2006

[19] Murray, D. et Al.: An Analysis of Changing Enterprise Network Traffic Character-istics. Murdoch University, 2017

[20] Netty API Website: Netty API Reference (4.1.17 Final) Available at: https://

netty.io/4.1/api/overview-summary.html, November 2017

[21] Intel Corporation Website, Intel Core Duo Processor T9400Available at: https://ark.intel.com/de/products/35562/

Intel-Core2-Duo-Processor-T9400-6M-Cache-2_53-GHz-1066-MHz-FSB,November 2017

[22] Intel Corporation Website, Intel Core 2 Duo Processor E8400Available at: https://ark.intel.com/de/products/33910/

Intel-Core2-Duo-Processor-E8400-6M-Cache-3_00-GHz-1333-MHz-FSB,November 2017

[23] Intel Corporation Website, Intel Core 2 Duo Processor T9400Available at: https://ark.intel.com/de/products/35562/

Intel-Core2-Duo-Processor-T9400-6M-Cache-2_53-GHz-1066-MHz-FSB, De-cember 2017

[24] Iptables info Website, Netfilter iptables Available at: http://www.iptables.info/

en/iptables-contents.html, November 2017

[25] Oracle Java Documentation Website, Java Programming Language Availableat: https://docs.oracle.com/javase/8/docs/technotes/guides/language/

index.html, November 2017

[26] Oram, A.: Peer-to-Peer: Harnessing the Power of disruptive Technologies. O’Reillyand Associates, Inc., Sebastopol, CA, USA, 1st edition, March 2001

BIBLIOGRAPHY 59

[27] Postel, J.: User Datagram Protocol RFC 768, RFC Editor, https://tools.ietf.org/html/rfc768, August 1980

[28] Project Purple Website, Project Purple Group Available at: http://www.earth.li/projectpurple/, November 2017

[29] Rosenberg, J. et Al.: STUN - Simple Traversal of User Datagram Protocol (UDP )Through Network Address Translators. RFC 3489, RFC Editor, Available at:http://www.rfc-editor.org/rfc/rfc3489, March 2003

[30] libjitsi sctp4j Github repository: sctp4j Available at: https://github.com/jitsi/libjitsi/tree/master/src/org/jitsi/sctp4j, November 2017

[31] sctp4nat Github repository: A simple Java SCTP via UDP library Available at:https://github.com/jonaswagner/sctp4nat, December 2017

[32] SendIP Info Website: SendIP Available at: https://www-x.antd.nist.gov/ipv6/

sendip.html, November 2017

[33] Skype Website: Skype Available at: https://www.skype.com/en/new/, November2017

[34] Srisuresh, P., Ford, B. and Kegel, D.: State of Peer-to-Peer (P2P) Communica-tion across Network Address Translators (NATs). RFC 5128, RFC Editor, Availableat:http://www.rfc-editor.org/rfc/rfc5128, March 2008

[35] Stewart, E.: Stream Control Transmission Protocol RFC 4960, RFC Editor, https://tools.ietf.org/html/rfc4960, September 2007

[36] Stewart, R. et Al.: Sockets API Extensions for the Stream Control TransmissionProtocol (SCTP) Available at: https://tools.ietf.org/html/rfc6458, December2011

[37] Tanenbaum, A. S., Wetherall, D. J.: Computer Networks (5th Edition).; PrenticeHall, pp. 713 - 734, 2011

[38] Tanenbaum, A. S., Wetherall, D. J.: Computer Networks (5th Edition).; PrenticeHall, pp. 552-581, 2011



[41] Tuexen, M., Stewart, E.: UDP Encapsulation of Stream Control Transmission Pro-tocol (SCTP) Packets for End-Host to End-Host Communication RFC 6951, RFCEditor, https://tools.ietf.org/html/rfc6951, September 2007

[42] TomP2P Website: A P2P-based high performance key-value pair storage library.Available at:http://tomp2p.net, November 2017

60 BIBLIOGRAPHY

[43] tomp2p Github repository: A P2P-based high performance key-value pair storagelibrary Available at: https://github.com/tomp2p/TomP2P, December 2017

[44] UDP-based Data Transfer Website: UDT: Breaking the Data Transfer Bottleneck.Available at: http://udt.sourceforge.net/

[45] usrsctp Github Website: A portable SCTP userland stack. Available at: https:

//github.com/sctplab/usrsctp, December 2017

[46] Wagner, J.: Hole Punching in P2P Networks with TomP2P. Bachelor Thesis, Com-munication Systems Group University of Zurich, April 2015

[47] Google Inc., WebRTC Home Available at: https://webrtc.org/, November 2017

[48] Whatsapp Website, Simple. Secure. Reliable messaging. Available at: https://www.whatsapp.com/?l=en, November 2017

[49] Wireshark Info Website, Wireshark - The World’s Foremost and Widely-Used Net-work Protocol Analyzer. Available at: https://www.wireshark.org/, November2017

[50] Wook Hyun, K., Dong-Sung, K. and Jae-Min, L.: Design and Implementation ofHome Network Systems using UPnP Middleware for Networked Appliances, Novem-ber 2001

[51] Cannonical Foundation, Ubuntu 16.04 LTS Xenial Xerus. Available at:http://releases.ubuntu.com/16.04/, November 2017

[52] Yunhong, G.: UDT: A Transport Protocol for Data Intensive Applications RFC In-ternet Draft, RFC Editor, https://tools.ietf.org/html/draft-gg-udt-00, De-cember 2003

Abbreviations

ACK AcknowledgementAPI Application Programming InterfaceCPU Central Processing UnitCSG Communication Systems GroupDHT Distributed Hash TableFEC Forward Error CorrectionGB GigabyteIETF Internet Engineering TaskforceIP Internet ProtocolIPv4 Internet Protocol Version FourIPv6 Internet Protocol Version SixJAR Java ArchiveJNI Java Native InterfaceMTU Maximum Transmission UnitMB MegabyteNAT Network Address TranslationNAT-PMP NAT Port Mapping ProtocolOS Operating SystemP2P Peer to PeerQUIC Quick UDP Internet ConnectionsRAM Random Access MemoryRTT Round Trip TimeSCTP Streaming Control Transport ProtocolTCP Transmission Control ProtocolUPnP Universal Plug’n’PlayUDP User Datagram ProtocolUDT UDP-based Data TransferUML Universal Modelling LanguageUZH University of ZurichVoIP Voice over IPWebRTC Web Real-Time Communication

61

62 ABBREVIATONS

List of Figures

2.1 Network Address Translation Example [46] . . . . . . . . . . . . . . . . . . 5

2.2 UDP Hole Punching Process [34] . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 After Hole Punching [34] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Common header of TCP packets [38] . . . . . . . . . . . . . . . . . . . . . 8

2.5 Common header of UDP packets [39] . . . . . . . . . . . . . . . . . . . . . 8

2.6 SCTP packet with chunks [5] . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 SCTP handshake [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.8 Multistreaming between Host A and Host B [5] . . . . . . . . . . . . . . . 10

2.9 Test setup for NAT behaviour investigation . . . . . . . . . . . . . . . . . . 15

3.1 The WebRTC datachannel protocol stack [13] . . . . . . . . . . . . . . . . 20

4.1 The six service primitives [40] . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 The designed protocol stack for SCTP via UDP connections. . . . . . . . . 26

5.2 Simplified sequence diagram of the transmission of data between two peersusing SCTP via UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 UML class diagram overview of the sctp4nat project . . . . . . . . . . . . . 29

6.1 The net.sctp4nat.origin Package . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 The net.sctp4nat.core Package . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3 The net.sctp4nat.connection Package . . . . . . . . . . . . . . . . . . . . . 37

6.4 The integration concept how TomP2P should establish SCTP via UDPconnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

63

64 LIST OF FIGURES

7.1 Test scenario used for the real-world test of sctp4nat . . . . . . . . . . . . 48

7.2 Test locations used [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

List of Tables

2.1 Transport Protocols applied to Real-Time Conferencing requirements . . . 12

2.2 Test results from the NAT test of SCTP and TCP Fast Open . . . . . . . 16

2.3 Table 2.1 complemented with the simplified results from Table 2.2 . . . . . 17

7.1 Test results from the Internet test of sctp4nat. . . . . . . . . . . . . . . . . 52

7.2 Test results from the consistency test of sctp4nat. . . . . . . . . . . . . . . 52

65

66 LIST OF TABLES

Appendix A

Installation Guidelines

The sctp4nat source code is available on the sctp4nat Github repository [31]. The pre-requisites of using sctp4nat are the following:

• The machine is required to have the Java Development Kit (at least version 8)installed.

• sctp4nat is only supported on linux, thus the use of Debian based systems (likeUbuntu 16.04) is suggested.

• The machine is required to have Gradle (at least version 4.1) installed.

• The machine needs to have the gcc compiler installed to be able to compile theusrsctp library.

Once the library is downloaded it can be compiled with Gradle and the Java DevelopmentKit compiler.

67

68 APPENDIX A. INSTALLATION GUIDELINES

Appendix B

Iptables Router Configuration ShellCommands

#! bin/bash

#remove network manager

apt-get purge network-manager -y

#remove old network settings

iptables -t mangle -F

dhclient ens2 -r

iptables -t nat -F

iptables -t filter -F

iptables -t raw -F

ifconfig ens2 down

ifconfig ens3 down

echo "assign ip to network interfaces"

echo "outside network"

ifconfig ens2 up

dhclient ens2

echo "subnet configuration"

ifconfig ens3 10.1.1.1/24

echo "subnet 10.1.1.0 netmask 255.255.255.0 {range 10.1.1.100 10.1.1.150;

option domain-name-servers 8.8.8.8, 192.168.0.1; option routers 10.1.1.1;

option broadcast-address 10.1.1.255; default-lease-time 600;

max-lease-time 7200;}" > /etc/dhcp/dhcpd.conf

echo INTERFACES=\"ens3\" > /etc/default/dhcp3-server

/etc/init.d/isc-dhcp-server restart

echo nameserver 192.168.0.1 > /etc/resolv.conf

echo "enable forwarding and nat traversal"

echo 1 >/proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o ens2 -j MASQUERADE

echo "Firewall configuration"

echo "Set the default Policy of INPUT to DROP, but accept the www traffic and

69

70 APPENDIX B. IPTABLES ROUTER CONFIGURATION SHELL COMMANDS

packages"

echo "which belong to already established connections"

iptables -t filter -P INPUT DROP

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

iptables -A INPUT -m state --state RELATED -j ACCEPT

#iptables -A INPUT -p tcp --sport 80 -j ACCEPT





echo "Set the default Policy of FORWARD TO DROP, but accept packages which

belong to"

echo "already established connections or source ip belongs to the 10.1.1.0/24

subnet"

iptables -t filter -P FORWARD DROP

iptables -t filter -A FORWARD -s 10.1.1.0/24 -j ACCEPT

iptables -t filter -A FORWARD -d 17.110.230.12 -j DROP

iptables -t filter -A FORWARD -m state --state ESTABLISHED -j ACCEPT

iptables -t filter -A FORWARD -m state --state RELATED -j ACCEPT

#show results

route -v

iptables -L -v

ifconfig -v

#Setup upnp

#/etc/init.d/miniupnpd restart

#iptables -A INPUT -i ens3 -p udp --dport 1900 -j ACCEPT

#/etc/init.d/miniupnpd stop

Appendix C

Linux Bash Test Scripts

Server Script

#!/bin/bash

COUNTER=100

SUB=1

until [ $COUNTER -lt 0 ];

do

echo "Time: $(date). HolePServer $COUNTER started"

./holep.sh >> output.txt

echo "Time: $(date). HolePServer $COUNTER shutdown"

COUNTER=$((COUNTER-1))

sleep 300

done

Client Script

#!/bin/bash

COUNTER=100

SUB=1

until [ $COUNTER -lt 0 ];

do

echo "Time: $(date). HolePServer $COUNTER started"

./holepclient.sh

echo "Time: $(date). HolePServer $COUNTER shutdown"

COUNTER=$((COUNTER-1))

sleep 300

done

71

72 APPENDIX C. LINUX BASH TEST SCRIPTS

Appendix D

Contents of the CD

Zusfsg.txt The german version of the Abstract of this thesis.

Abstract.txt The english version of the Abstract of this thesis.

MasterThesis.pdf The digital (pdf) version of this thesis.

Intpr.pdf The intermediate presentation of this thesis.

sctp4nat.jar The compressed source code of this thesis.

thesis.zip The compressed Latex source including all pictures of this thesis.

Evaluation.zip A compressed version of the internet test of this thesis. This file con-tains two folders. The Internet Test folder contains two runnable Java Archive(JAR) files (holepclient.jar and textitholepserver.jar) and the Wireshark pcapng file(internet test.pcapng). The Consistency Test folder also contains two JAR files(also called (holepclient.jar and textitholepserver.jar) and the respective Wiresharkpcapng file (holep100.pcapng). Also the folder contains the shell scripts used for thetest (holepclient.sh and holepserver.sh) and the log output of the server (output.txt).

73

Documents

SCTP Support For P2P Applications With TomP2P · (Stream Control Transmission Protocol) with respect to real-time conferencing, stored media streaming and possibilities of NAT traversal