This paper evaluates the performance of data transmission using the ordinary PC both for large sized data transmission and for the actual application. As an actual application, this paper picks up the DV (Digital Video) transmission. This is because the Digital Video will be a common and widely used application media in the emerging internet. Also, the video contents requires the secured and reliable data transmission. For large sized data, when we apply the authentication (AH) and encryption (ESP), the throughput degrades to 1/9 comparing with the throughput without AH nor ESP. With AH and ESP, we obtains about 10 Mbps for UDP data transmission and about 6 Mbps for a simple TCP transmission. As for the DV transmission, the end-to-end throughput was again about 10Mbps. With 10 Mbps end-to-end throughput, the 1/10 of video information can be successfully transferred from the source node to the destination node to obtain a sufficient quality of DV transmission.

1. Introduction

        As the Internet moves forward into the next century, the Internet transits to an information infrastructure for everyone from the information infrastructure only for scientists or professionals. The next generation Internet has to achieve the scalable and reliable data transmission. The IPv6 (IP version 6) [4] and IPSec (IP Security) [1] is a core protocol suite for it. IPv6 has a 128bit address space that is enough to cover all worldwide networks and equipment, and IPSec technology provides a essential functions for reliable and secured data exchange over the Internet.
        The purpose of this paper is a performance evaluation of data transmission with the IPSec over IPv6 networks using an ordinary PC platform. People wants to perform a high speed multimedia communications, such as high quality video communications, with a low cost PC platform. Also, when we go to the production level of multimedia services over the Internet, we have to apply the authentication and encryption to protect themselves and the information exchanged among them.
        This paper evaluates the performance of data transmission using the ordinary PC both for large sized data transmission and for the actual application. As the actual application, this paper picks up the DV (Digital Video) transmission, since the secured and reliable DV applications will be commonly used by the most of the people in the next generation Internet.
        For large sized data, when we apply the authentication (AH) [2] and encryption (ESP) [3], the throughput degrades to 1/9 comparing with the throughput without AH nor ESP. With AH and ESP, we obtains about 10 Mbps for UDP data transmission and about 6 Mbps for TCP transmission. Also, the throughout was compared with the data transmission with IPv4. The degradation of throughput at the end system, due to the use of IPv6 instead of IPv4, was significantly small.

The performance evaluation in this paper shows ;

• Even with an ordinary PC platform, we can perform the secure and reliable DV quality multimedia data transmission using the AH and ESP over IPv6 network

• The performance degradation or improvement of data transmission throughput due to the introduction of IPv6 is not significant for end system

Section 2 discusses the rough overview of IPSec, section 3 describes the performance evaluation of bulk data transmission over TCP and UDP. Section 4 describes the performance evaluation of DV data transmission with applying the IPSec. Finally, section 5 gives a brief conclusion.

2. IPSec (IP Security)

        RFC 2401 [1] describes the architecture framework of IPSec (IP Security). IPSec protocol suite provides the functional suite for secured and reliable data exchange over the Internet. IPSec has the following two functions, i.e., Authentication and Encryption.
 

• Authentication

The authentication is a user validation of the communication peer. In order to validate (authenticate) the user, IPSec defines the AH (Authentication Header) in RFC2402 [2]. AH field contains the digital signature calculated by the sender node. The receiver node validates the digital signature in the received AH field. When the AH contains the valid digital signature, the received packet is correctly delivered to the corresponding application module. On the other hand, when the AH does not contains the valid digital signature, the received packet is discarded. With the AH, the receiver can receive the packets only from the authenticated node/user.
 
• Encryption

The encryption is to allow to be able to read a data by only person(s) who has (have) the correct encryption key. In order to encrypt the user data in the IP packet, IPSec defined the ESP (Encapsulating Security Payload) in RFC2403 [3]. ESP field contains the encryption parameters to identify the encryption scheme between the communicating peer nodes. The payload of IP packet contains an ESP header, that has the encryption parameter, and the encrypted user data. In other word, the encrypted user data is encapsulated into the container, whose header is an IP header and an ESP header.

3. Performance Evaluation of Bulk Data Transmission

        In this section, we evaluate the performance of bulk data transmission. The performance is evaluated with the STREAM data transmission and with the REQUEST/RESONSE data transmission. Regarding the transport protocol, both TCP and UDP are applied to.

3.1 Evaluation System
        The end-to-end throughput was evaluated using the netperf (http://www.netperf.org/) with the KAME IPv6 protocol stack. The patch for to use netperf 2.1pl3 with KAME IPv6 stack is available through the following ftp directory.
 

ftp://ftp/kame.net/pub/kame/misc/netperf-21pl3-19990824.diff.gz.

• Host
CPU : Intel Pentium II 450 MHz
Memory : 128MB
NIC : Intel EtherExpress Pro 100
OS : FreeBSD 2.2.8 with KAME 19990908-stable
 
• Router
CPU : Intel Pentium III 500MHz
Memory : 256MB
NIC : Intel EtherExpress Pro 100
          DEC 21040 PCI Ethernet
OS : FreeBSD 2.2.8 with KAME 19990908-stable

The end-to-end throughput is evaluated in the following cases.

• without IPSec
• Only with AH (Authentication Header)
  (HMAC-SHA1 160 bits)
• Only with ESP (Encapsulated Security Payload)
  (3DES-CBC 192bits)
• Both with AH and ESP

3.2 Evaluation Results

3.2.1 TCP STREAM
        Figure 2 shows the end-to-end throughput using IPv4, and figure 3 shows that using IPv6. Here, the MTU size is 4,096 Bytes, the socket size is 57,344 Bytes and is 32,768 Bytes.
 

TCP_STREAM.1 : socket buffer size = 57,344 Bytes
TCP_STREAM.2 : socket buffer size = 32,769 Bytes

The end-to-end throughput is degraded by the processing of IPSec. With the AH, the end-to-end throughput degrades to about 1/2 With the ESP, the end-to-end throughput degrades to about 1/4. With both the AH and the ESP, the end-to-end throughput is slightly less than with only ESP.

Regarding the IP version, the end-to-end throughput with IPv6 is almost the same as that with IPv4.

 
3.2.2 UDP STREAM
        Figure 4 shows the end-to-end throughput using IPv4, and figure 5 shows that using IPv6. Here, the MTU size is 4,096 Bytes and is 1,024 bytes, and the socket size is 32,768 Bytes.
 

UDP_STREAM.1 : MTU size = 4,096 Bytes
UDP_STREAM.2 : MTU size = 1,024 Bytes

The end-to-end throughput is degraded by the processing of IPSec. With the AH, the end-to-end throughput degrades to about 1/3. With the ESP, the end-to-end throughput degrades to about 1/9. With both the AH and the ESP, the end-to-end throughput is slightly less than with only ESP. Also, when the MTU size is larger, the end-to-end throughput is slightly improved.  Again, regarding the IP version, the end-to-end throughput with IPv6 is almost the same as that with IPv4.

3.2.3 REQUEST/RESPONSE
        Figure 6 shows the end-to-end throughput using IPv4, and figure 7 shows that using IPv6.
 

TCP_RR    : Request message = 1 Byte, Response message = 1 Byte
UDP_RR.1 : Request message = 1 Byte, Response message = 1 Byte
UDP_RR.2 : Request message = 516 Byte, Response message = 4 Byte

With TCP_RR and UDP_RR.1, the throughput with ESP is larger than the throughput with AH.  With UDP_RR.2
(i.e., large message size), the throughput with ESP is smaller than the throughput with AH.  And, again, regarding the IP version, the end-to-end throughput with IPv6 is almost the same as that with IPv4.

3.2.4 Discussion

3.2.4.1 STREAM Data Transmission
        By the AH and ESP processing at the end hosts, the end-to-end throughput degrades, when we use the IPSec.  AH performs the hash function, and ESP performs encryption.
        Without applying the IPSec, the end-to-end throughput over TCP is less than the end-to-end throughput over UDP. This is because the TCP requires larger processing than the UDP does.  However, when we use the IPSec, the end-to-end throughput over TCP and over UDP is almost the same.  This is the simple proof, that the processing for IPSec is far larger then that for TCP and UDP.
        When we compare the end-to-end throughput with AH and with ESP, the throughput with AH is about twice larger than that with ESP.  This is because, with STREAM data transmission, the packet size is large enough than the header length
(basic IP header field and AH field), and the required processing for ESP is far larger than that for AH.   As shown in figures 4 and 5, when the MTU size becomes larger, the end-to-end throughput degrades.  The degradation with ESP is smaller than with AH, since the AH uses IP packet header field and the ESP uses a whole of payload in IP packet.  Also, since the processing for ESP is large enough than that for AH, the performance degradation from only ESP system to ESP/AH system is not large.
        In summary, for large sized data (i.e., STREAM data transmission), when we apply the authentication (AH)  and encryption (ESP), the throughput degrades to 1/9 comparing with the throughput without AH nor ESP.  With AH and ESP, we obtains about 10 Mbps for UDP data transmission and about 6 Mbps for TCP transmission.  Also, the throughout was compared with the data transmission with IPv4. The degradation of throughput at the end system, due to the use of IPv6 instead of IPv4, was significantly small.

3.2.4.2 REQUEST/RESPONSE Data Transmission 
        With the REQUEST/RESPONSE data transmission, the end-to-end throughput degradation by applying the IPSec is less than that with the STREAM data transmission.  This is because the processing overhead for request messages is not significantly small, compared to the processing overhead for IPSec, and because the packet size is not large.

4. Performance Evaluation of DV Data Transmission
         In this section, we evaluate the end-to-end DV data transmission over IPv6 network.  The reason why we pick up the DV transmission is that the DV will be a common and widely used application media in the emerging internet.  Also, the video contents requires the secured and reliable data transmission.

4.1 Evaluation System
          Figure 8 shows the system configuration of evaluation system. The end host are connected through the three routers and wide area high speed ATM links.  Nodes have the fast Ethernet interfaces and the ATM interfaces.  The followings are the specification of hosts and routers.  In order to send and receive the DV data, we use the DVTS developed by Keio University [6].

• Sender Host
CPU : Intel Pentium II 400 MHz
Memory : 64MB
NIC : Intel EtherExpress Pro 100
OS : FreeBSD 3.2 with KAME 19990810-stable
Sender software : DVTS-0.0.9
 
• Receiver Host
CPU : Intel Pentium II 450 MHz
Memory : 128MB
NIC : Intel EtherExpress Pro 100
OS : FreeBSD 3.2 with KAME 19990810-stable
Sender software : DVTS-0.0.9
 
• Router
CPU : Intel Pentium III 500MHz
Memory : 256MB
NIC : Intel EtherExpress Pro 100
          DEC 21040 PCI Ethernet
OS : FreeBSD 2.2.8 with KAME 19990908-stable

• ATM Link
Bandwidth : 155 Mbps
 

 
Figure 8. System configuration for DV data transmission

The end-to-end throughput is evaluated in the following cases.

• NONE : without IPSec
• AH1 : only with AH (Authentication Header) using  HMAC-SHA1 160bits
• AH2 : only with AH using KEYED-SHA1 160bits
• ESP1 : only with ESP (Encapsulated Security Payload) using 3DES-CBC 192bits
• ESP2 : only with ESP using BLOWFISH-CBC 192bits
• AH/ESP 1 : both with AH1 and ESP1
• AH/ESP 2 : both with AH2 and ESP2

4.2 Evaluation Results
        Figures 9 and 10 shows the end-to-end throughput using the experimental network shown in figure 8.

        As for the DV transmission, the end-to-end throughput was about 7 Mbps to 17 Mbps with IPSec.  With 10 Mbps, we can not transmit the full rate quality of DV data.  However, we can transfer the DV data with reducing the sending frame rate.  The DVTS, that is DV transmission and receiving software module, can control the frame rate sent out from the sender node.   With the evaluation result, the 1/10 of video frames are transferred from the source node to the destination node, so as to the required bandwidth is around 10Mbps.  Even with 1/10 of video frame rate, we can not obtain a fine quality of video transmission.  However, we can obtain a sufficient video quality for many applications, such as video conferencing, with this reduced frame rate.

        The result above shows that the existing ordinary PC platform could handle the high quality video transmission using the DV technology, without any special hardware assistance.  This is even when we apply the IPsec technology to provide the secured and reliable multimedia communication over the Internet.   The current ordinary PC platform can not handle the plain DV data with the full frame rate while applying the IPSec functions.  However, due to the fast technological improvement for the PC components (e.g., CPU), it would be expected the ordinary PC platform can handle the full frame rate DV data without any special hardware.

References

[1] S.Kent, R.Atkinson, "Security Architecture for the Internet Protocol", IETF RFC2401, November 1998.
[2] S.Kent, R.Atkinson, "IP Authentication Header", IETF RFC2402, November 1998.
[3] S.Kent, R.Atkinson, "IP Encapsulation Security Payload (ESP)", IETF RFC2403, November 1998.
[4] S.Deering, R.Hinden, "Internet Protocol version 6 Specification", IETF RFC2460, November 1998.
[5] J.Postel, "Internet Protocol", IETF RFC791, September, 1981.
[6] DVTS, http://www.sfc.wide.ad.jp/DVTS/