Internet Draft Hosei Matsuoka Date: October 20, 2004 Takeshi Yoshimura Expires: April 2004 NTT DoCoMo Problem Statement and Requirements for Multi-link Transport draft-matsuoka-multilink-transport-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Multi-link transport can offer higher bandwidth and more robust connections. Because of a wide variety of emerged wireless access technologies, a mobile host can potentially have subscriptions and access more than one wireless network simultaneously. This document introduces example applications which use multiple links in a connection simultaneously and illustrates the advantages of multi-link transport. A problem with those applications is that the efficient multi-link transport needs much more knowledge about each link characteristics such as bandwidth, delay, reliability and robustness. This document defines the requirements for efficient and adaptive multi-link transport and also describes the link information that multi-stream senders can require. 1. Introduction Because of a wide variety of emerged wireless access technologies, a mobile host can potentially have subscriptions and access more than one wireless network simultaneously. Combining different network accesses, a mobile host can take advantage of each network's feature such as higher bandwidth and robust connections. For example, having both cellular network link and wireless LAN network link offers "always-on" Internet access and high-speed wireless LAN access within wireless LAN coverage areas. Hosei, et al. Expires April, 2004 [Page 1] Internet-Draft Multi-link Transport October 20, 2003 With multiple streams, more advanced usages are possible. One of the examples is the layered coded[1] video streaming. The video content consists of the base layer and the enhancement layers. The base layer data without which reconstruction fails completely is transmitted through the most reliable and robust path and the enhancement layer data is transmitted through the other path. In this case, the receiver which has a cellular network access and a wireles LAN access can always receive the base layer through the cellular network and also receive the enhancement layer when being within wireless LAN coverage areas, thus improving the video quality. To split data to multiple links correctly, multi-stream senders need much more knowledge about the receiver's links as well as their own ones. However there is no protocol which allows multi-stream senders to realize the characteristics of receiver's links sufficiently. Without such link information, the ability of multi-link transport can be limited. This document presents some example applications which illustrate the advantage of multi-link transport, and then defines the requirements for efficient and adaptive multi-link transport. It also describes the link information that multi-stream senders can require for efficient data striping. Since different wireless links have their own specific parameters and using these parameters at the upper layer may be the layer violation, the link information needs abstraction. 2. Example Applications This section presents some example multi-link transport applications and the scenarios. 2.1 Bandwidth Aggregation A simple advantage of multipath transport is bandwidth aggregation. It is achieved by striping data across the multiple interfaces of the mobile host. The simplest striping scheme is round robin striping where the sender sends packets in round robin order on the paths. However, since different path has different characteristics in terms of bandwidth, delay, and loss rates, most of data striping shemes are performed in consideration of these parameters. Congestion control mechanisms based on the receiver's acknowledgement can adjust the appropriate data rate to the path condition and estimate the bandwidth. Striping data over multiple TCP connections needs the resequencing to manage the buffer bundling multiple connections. If one of the receiver's interfaces becomes disabled, the TCP connection using this interface may stall the other TCP connections. Although decoupling the loss recovery from congestion control avoid this stall[2], the link up/down notification[3] from the receiver would be useful also. Hosei, et al. Expires April, 2004 [Page 2] Internet-Draft Multi-link Transport October 20, 2003 2.2 Multiple Description and Layered Coding Video streaming applications may need a higher bandwidth and higher reliability connection than that provided by a single path. Two viable multipath strategies for video coding are multiple desctiption(MD) coding[4] and layered coding[1]. Both coding techniques produce multiple sub-streams that can be carried on different paths. With MD coding, each sub-stream has equal importance and can be decoded independently. One sub-stream can provide a basic level of reconstruction quality and additional sub-streams can further improve the quality. The loss of one sub-stream does not influence other sub-streams. With layered coding, there is one base layer stream which provides a basic level of quality. The other sub-streams are called enhancement layer, which serve to refine the base layer quality. Since the reconstruction fails completely without the base layer stream, the enhancement layers alone are not useful. For both video codings, the knowledge of each path condition can helps the efficient video coding. Obviously, the choice of the path for base layer also depends on the path condition. 2.3 IP Soft Handover (Bicasting) Some terminal mobility technologies such as Mobile IP offer IP handover. However, until the sender is notified of the new address, packets can still be dropped during handover. While retransmission can recover missing packets, this is inadequate for real-time applications because delays can seriously decrease the quality of applications. Simultaneous bindings in Mobile IP[5][6] enables the mobile node to register multiple care-of-addresses to the sender. This results in bicasting or n-casting of packets to all the care-of-addresses and reduces the packet loss duration to the time required by the Layer-2 handover. This kind of techniques are useful for rapid back and forth movement between two wireless access points. It can occur if radio conditions for both access points are not enough to establish a good connection. IP soft handover with multiple interfaces [7] eliminates the packet loss doubling the connection's bandwidth during handover. A host can use more than one IP network interface within a connection, and choose the source and destination addresses with the highest signal strength. When the mobile node is in a cell-overlap region and both links have a weak signal strength, the correspondent node bicasts to both interfaces of the mobile host. If the signal strength of one link exceeds a certain threshold, then the correspondent node stops bicasting. 3. Problem Statement The example applications described above possess a common problem. While multi-homing allows hosts to use multiple source and destination addresses in a connection, multi-stream senders need much more knowledge about each link of the receiver such as bandwidth, delay, reliability and robustness in order for efficient multi-link transport. Hosei, et al. Expires April, 2004 [Page 3] Internet-Draft Multi-link Transport October 20, 2003 When congestion control is performed at a certain layer, the end-to-end bandwidth and round-trip delay can be estimated, but these parameters cannot be realized until a certain amount of data is transmitted. And even if these parameters are realized, it may still not enough for some multi-stream applications. The example applications like section 2.2 or section 2.3 may need much more knowledge about reliability and robustness. Real-time constraint applications generally do not use the congestion control mechanism. Those applications can get some statistics of data transport by using RTCP receiver's report, but these statistics also cannot be realized until a certain amount of data is transmitted. And these parameters may not enough information for some multi-stream applications. Without these parameters, the only thing multi-stream senders can do is something sort of round-robin data striping. It is not useful when the receiver has two or more different links that have the diverse characteristics. For efficient and adaptive multi-link transport, multi-stream senders need much more knowledge about the receiver's links. 4. Requirements This section describes the requirements of multi-stream transport. o Multi-stream senders can obtain the characteristics of the correspondent's links involved in the connection. As described in the problem statement, efficient multi-link transport needs much more knowledge about correspondent's links. Multi-stream senders should note that depending on the last-hop characteristics is suboptimal or even may cause the negative impact adversely. o Data path can be selected based on the application data priority. Some multi-stream applications prioritize application data and intend to split high-prioritized data and low-prioritized data into different paths. Data path is determined by choosing a pair of source and destination addresses. o Multi-stream senders can detect status changes of the correspondent's links involved in the connection as soon as they happen. Wireless link states are time-variant and come under the influence of terminal movement. Status changes may affect the path selection and multi-stream senders have to readjust the data path for each application data. Hosei, et al. Expires April, 2004 [Page 4] Internet-Draft Multi-link Transport October 20, 2003 5. Link Information This section describes the link information that multi-stream senders may require for multi-link transport. There are two types of link information. one is link property which is static information inherent to the link, and the other is link status which is dynamically changeable and time-variant. Using detail information specific to a particular link at the upper layer may be layer violation and reduce the flexibility of the layer principle. Therefore, the link information has to be represented by abstracted parameters for the upper layers. 5.1 Link Property o Link Bandwidth This information is necessary to realize the maximum data rate for each link. For striping data across multiple links, this information is primary hint for adjusting how much amount of data for each link. o Link Delay This information helps delay-constraint multi-stream applications. If some pieces of data are real-time constraints but others are not, real-time constraint data can be transmitted through the faster link, and the other data is transmitted through the slower link. For example, video and audio data is real-time constraint but timed-text data is not so real-time constraint. Another advantage is reordering the video frame to be transmitted. For example, RTP payload format for H.264 video[8] has a DON (Decoding Order Number) field to provide flexibility of transmission order. Sending important frame through the faster path may allow for the retransmission of the lost frame. o Link Robustness This information indicates the robustness of the links against terminal movement. Wired links never suffer from the variation in quality as long as connected. Cellular links such as GPRS links cover large areas, so the short movement of the host does not really affect the link status. Small-cell wireless links such as wireless LAN links covers the small areas (usually inside buildings) and even short movement may affect the link status. o Link Reliability This information indicates whether the link layer provides reliability through the use of retransmission. It is relevant to signal strength. When the link layer does not provide reliability, a low signal link may suffer from the high loss rate. On the other hand, when a link layer provides reliability, a low signal link may suffer from additional link delay caused by retransmission. Hosei, et al. Expires April, 2004 [Page 5] Internet-Draft Multi-link Transport October 20, 2003 5.2 Link Status o Signal Strength The signal strength parameter is specific to wireless link and mainly used for the handover mechanisms. For example, the mobile node which has two wireless LAN links chooses the receiving interface with higher signal strength. As introduced in section 2.3, when both links have a weak signal strength, bicasting can be required. 6. Security Consideration To enable multi-link transport, a multi-link receiver needs to tell the sender its IP address information and link information. The message of IP address information to an existing association possesses a connection hijacking problem. If the attacker intercepts and alters the IP address information of the message, packets will be sent to the attacker. And also the link information modified by the attacker will cause service disruption. Therefore, a message authentication mechanism is necessary to prevent these attacks. For bicasting or n-casting, the receiver can request the same packet stream for another IP address, even the other host's IP address by falsifying the IP address information. Therefore, the valid host which is eligible to get a service can copy the service for non-valid users. Therefore, identity and message authentication functionalities are necessary. The receiver of messages about IP address and link information will have to verify the validity of the messages. As another security problem with multi-link terminals, multi-wireless-link host can become a wireless router and easily pretend to be the default router in the wireless link by advertising routing information. The other hosts in the same wireless link send packets through the wireless router, and might suffer from the man-in-the-middle attack on the malicious wireless router. 7. Closing Statements While this work is initially focusing on dual wireless terminals equipped with a cellular access link and a Wireless LAN access link, the draft does not limit the case and it needs solutions that can accomodate any combination of all kinds of links. Hosei, et al. Expires April, 2004 [Page 6] Internet-Draft Multi-link Transport October 20, 2003 8. References [1] Sanguen Han and Bernd Girod "Robust and Efficient Scalable Video Coding with Leaky Prediction", InProceedings of ICIP 2002, September 2002. [2] Hung-Yun Hsieh and Raghupathy Sivakumar "A Transport Layer Approach for Achieving Aggregate Bandwidths on Multi-homed Mobile Hosts", InProceedings of MOBICOM 2002, September 2002. [3] Spencer Dawkins, Carl E. Williams and Alper E. Yegin "Problem Statement for Triggers for Transport(TRIGTRAN)" draft-dawkins-trigtran-probstmt-01.txt [4] Ali Begen, Yucel Altunbasak and Ozlem Ergun "Fast Heuristics for Multi-path Selection for Multiple Description Encoded Video Streaming", InProceedings of ICME 2003, July 2003. [5] Karim El Malki, Hesham Soliman, "Simultaneous Bindings for Mobile IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-03.txt, May 2003. [6] C. Perkins, "IP Mobility Support for IPv4", RFC3220, January 2002. [7] H.Matsuoka, T.Yoshimura and T.Ohya "A Robust Method for Soft IP Handover", IEEE Internet Computing Magazine, Vol.7 Num.2 pp.18-24, March/April 2003. [8] S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer "RTP payload Format for H.264 Video" draft-ietf-avt-rtp-h264-02.txt, June 2003. 9. Contact Information Hosei Matsuoka Multimedia Laboratories, NTT DoCoMo 3-5, Hikarinooka Yokosuka Phone: +81 468 40 3515 Kanagawa 239-8536 Fax: +81 468 40 3788 Japan E-mail: matsuoka@spg.yrp.nttdocomo.co.jp Takeshi Yoshimura Multimedia Laboratories, NTT DoCoMo 3-5, Hikarinooka Yokosuka Phone: +81 468 40 3515 Kanagawa 239-8536 Fax: +81 468 40 3788 Japan E-mail: yoshimura@spg.yrp.nttdocomo.co.jp Hosei, et al. Expires April, 2004 [Page 7]