Mobile IP Working Group Cedric Westphal Internet Draft Charles Perkins Expires: August 2002 Nokia Research Center Informational February 2002 Some Heuristics about Piggybacked Binding Updates draft-westphal-mobileip-piggyback-bu-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with 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 obsoleted 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 This document presents some simple analytical results with respect to the performance improvement brought by piggybacking binding updates (BUs). We see that the improvement in term of bandwidth is not significant unless the mobile terminal sending BUs moves very fast. We also see on the other hand that the improvement in term of jitter is quite significant in most situations. Westphal, Perkins Expires August 2002 [Page 1] Internet Draft Piggyback performance February 2002 Contents Status of This Memo 1 Abstract 1 1. Introduction 2 2. Assumptions 3 3. Bandwidth Gain Using Piggybacking 3 3.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Some numerical examples . . . . . . . . . . . . . . . . . 4 3.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 5 4. Jitter Induced by Piggybacking 5 4.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Numerical values . . . . . . . . . . . . . . . . . . . . 6 4.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusion 8 6. Intellectual Property Right Considerations 8 7. Acknowledgements 8 Authors' Addresses 8 Full Copyright Statement 9 1. Introduction In this short document, we present some analytical intuition with respect to piggybacking. Piggybacking is the insertion of a binding update (BU) into a regular payload packet sent from the mobile node (MN) to the correspondent node. Attaching the BU to a packet that goes to the same destination saves the MN from sending a BU in a separate packets, and optimizes the resource. In this document, we investigate how much bandwidth is economized this way, and how jitter is reduced. Westphal, Perkins Expires August 2002 [Page 2] Internet Draft Piggyback performance February 2002 2. Assumptions We consider a MN talking to a CN. The MN is connected to an access router (AR) via a bandwidth constrained wireless link. We consider the bandwidth consumed on this link with and without the use of piggybacking. A BU is sent, via piggybacking or independently, every time the MN moves away from a cell, and changes access router, or every time the life time of the BU expires. We assume that the time spent at the AR by the MN is T_cell . This is the time spent in one cell before the MN moves to the next cell. We denote by T_lt the life time of a BU. MN sends packets to the CN in a stream. Piggybacking applies only to stream, as it needs a payload packet as a carrier to transport the BU. Isolated packets do not need to update the CN about the movement of the MN. We denote by T_flow the time length of a connection or packet stream. We denote by Pi the packet rate within this stream and by s the packet size of the packets within this stream. We are considering the long term effects of piggybacking in terms of bandwidth. This means that, as the bandwidth use and the BU count are additive quantities, we only need to consider the deterministic mean values of T_cell ,Pi, s or T_flow . We denote by H_bu the size of an independent BU, H_ip the size of a IP header, and h = H_bu + H_ip the added size to a payload packet by piggybacking. 3. Bandwidth Gain Using Piggybacking 3.1. Analysis We define the BU rate to be: lamba_bu = max (1/T_cell,1/T_lt) (1) The bandwidth B_pb use with piggybacking and B_wo without are, per flow: B_pb = T_flow ((s +H_ip )Pi + h lamba_bu ) Bwo = T_flow ((s +H_ip )Pi + H_bu lamba_bu ) and the improvement ratio r_pb is given by (B_pb/B_wo): B_pb (s+H_ip)Pi + h lambda_bu r_pb = ---- = ----------------------------- B_wo (s+H_ip)Pi + H_bu lambda_bu h 1 - h/H_bu = ---- + -------------------------------- (2) H_bu 1 + lambda_bu (H_bu/Pi(s+H_ip)) This last quantity decreases from 1 for lamba_bu = 0 to (h/H_bu) as lamba_bu grows to infinity. The inflexion point (or cutoff value as this diagram is that of a lowpass filter plus some fixed gain) in the Westphal, Perkins Expires August 2002 [Page 3] Internet Draft Piggyback performance February 2002 Bode diagram is for (s+H_ip)Pi lamba_bu = ------------- (3) H_bu and achieves a ratio r_pb = 0.66 (4) We plot the Bode diagram in Figure 1. 1 |-------- | \ | \ | \ | \ | \ | `----------- .33+--------------------------- .01 1 100 10000 Fig. 1. Lowpass filter 3.2. Some numerical examples If we assume some typical values for VoIPv6 streams, h = 30 bytes, including authentication option, H_bu = 90 bytes, H_ip = 40, Pi = 1/20 ms^(-1) , and s = 20 bytes. The best possible achievable ratio is thus h/H_bu = 0.33, if the BU rate is infinite. The worst possible ratio is attained for the minimal value of lamba_bu = 1/T_lt . T_lt is typically of the order of 60 s, which yields a ratio r_pb = 0.9999. The cutoff value is: (s +H_ip )Pi lamba_bu = --------------------- = 33 BU per second (5) H_bu For lambda_bu equal to 1 BU per second, we attain r_pb = 0.98, for lambda_bu equal to 10 BU per second (one BU every 100 ms), r_pb is about 80%. For these values of the parameter, a significant gain is achieved for more than one BU per second. Note that the assumption is of one BU per flow to the CN. If a MN has several flows to the same CN, then, as far as average bandwidth is concerned, they can be aggregated into Westphal, Perkins Expires August 2002 [Page 4] Internet Draft Piggyback performance February 2002 one single flow with larger packet size s. The larger the packet size, the smaller the gain from piggybacking. 3.3. Conclusion Piggybacking has an impact of 0.2% for one BU every 10s, 2% for a BU every second and for small packet sizes (20 bytes). This means that: - if VoIP in cellular network is the goal, there is no need for piggybacking, as handoff frequency is in the order of the minute. - if bigger packets are transmitted, for video streaming, then there is no need for piggybacking either, as the packet size increase cancels the increase in the BU frequency induced by smaller cells - if several streams are transmitted from the CN to the MN, then there is less need for piggybacking either. - for packets that do not belong to a stream, there is no use for piggybacking. - if LMM mechanism is used to reduce the frequency of the binding updates, then it makes piggybacking less valuable. For instance, BETH with a 5 hops tunnel brings a potential gain of 5% down to 1%. item if Header Compression is applied, it reduces H_ip adding to the value of piggybacking. However, H_bu most probably can be compressed as well (at least static info is the same). A decrease of H_bu from 90 to 60 bytes decreases the maximal gain from 66% to 50% for infinite BU rate. For a BU rate of one BU per second, if H_ip is compressed to 0 byte and H_bu to 60 bytes, then the achieved ratio is r_pb = 1 - 0.03, or a 3% saved bandwidth, instead of 2%. The gain is not significant. This is a very simple analysis. However, I think it is telling not to go to war for piggybacking on the ground of bandwidth gain. 4. Jitter Induced by Piggybacking 4.1. Analysis A quantity of interest affected by piggybacked BUs is the jitter perceived by a stream of packets. Keeping the notations from section II, and denoting by c the capacity per unit of time of the channel, and t_a the time to access and to release the channel. In this situation, the added delay between two packets from the same flow caused by the BU is: Westphal, Perkins Expires August 2002 [Page 5] Internet Draft Piggyback performance February 2002 delta_wo = t_a + H_bu/c without piggybacked BUs delta_pb = h/c with piggybacking (6) This is the jitter only at a given link, note that this jitter can be amplified by having several hops within the network. The relative improvement with respect to jitter is thus: delta_pb h r_j = ------------- = -------------- (7) delta_wo c t_a + H_bu The minimum improvement, corresponding to the maximal value of r_j , is for a link with no delay to access or release the channel, or for links with little capacity. The maximum value is ( h/H_bu ). For link with some delay to access or release the channel and large capacity, the gain of piggybacking the BUs increases with the link capacity c as r_j (c) decreases to 0. 4.2. Numerical values We consider again the values h = 30, H_bu = 90. In a slow link or when there is no delay to access the channel, namely t_a = 0, piggybacking the BUs reduces the jitter created by the BU by a factor 3. Assume the capacity to be 100 kbits per second. Not piggybacking the BUs adds a delay delta_wo - delta_pb of 4.8 ms. Assume the capacity to by 25 kbits per second, the extra delay of sending a separate BU is about 20 ms. Assume now the time to release and access the channel t_a to be 20 ms. Then for the capacity 100 kbits/s, the extra delay delta_wo - delta_pb is 25 ms, for the capacity 25 kbits/s, the extra delay is 45 ms. The relative gain r_j is 0.09 for c = 100 kbits : the jitter is reduced by more than 90 % by piggybacking the BUs. For the capacity 25 kbits/s, the gain is an 80 % reduction of the jitter. As for instance [1] and other references point out, an access delay of 10 ms is a quite common occurrence. For a 2Mb/s station with 25 MNs, a 20 ms delay is attained for a total load of 1 Mb/s. As the load increase to 1.5Mb/s, so does the delay to 40ms. A value of t a equals to 40ms would mean the user would perceive this delay. Note the system is loaded with 1.5Mb/s, but is far from being saturated. Note that the throughput degrades, and thus c diminishes. However, the delay (H_bu - h)/c is never significant with respect to t_a . In figure 3, we present the additional delay induced by not piggybacking. To obtain this delay, we extracted from [1] the time to access the channel and added the time to transmit the H_bu- h over the channel. Figure 3 plots the additional delay against the load of the network. The load in the network varies from 0% to 100%, at Westphal, Perkins Expires August 2002 [Page 6] Internet Draft Piggyback performance February 2002 ms 50 | _______ 25 users | / 45 | / | / 40 | / | | 35 | / | / 30 | / | / 25 | / | | 20 | / _______ 8 users | / / 15 | / / | / /-/ 10 |----------- /-/ | /-/ 5 | /---------/ |<------------------------------ 2 users 0 +------------------------------- 0 10 20 30 40 50 60 70 80 90 100 load on the system Figure 3: Added delay by not piggybacking the BUs wrt Link Congestion which point the full capacity of the 2Mbps link is reached. The actual throughput is lower of course. The delay is plotted for 2 users, 8 users and 25 users sharing this link. This situation is a pretty common situation: piggybacking reduces on this link a jitter that the user would otherwise perceived. 4.3. Conclusion There is a significant gain in smoothing the jitter by piggybacking the BUs, especially when either the bandwidth is constrained or the acquisition time for the channel is long. Both situations being quite common, this illustrate the need for piggybacking. Westphal, Perkins Expires August 2002 [Page 7] Internet Draft Piggyback performance February 2002 5. Conclusion We have considered the impact of piggybacking the BUs over a single link with respect to bandwidth and to jitter. In the former, the gain requires a high rate of BUs to be significant. In the latter, the gain is obvious for high channel acquisition times or in low bandwidth links. In a tight link, the jitter is more significant, as the link may not be able to recover from the variation in packet arrival times, and the jitter translates into delay for subsequent packets. 6. Intellectual Property Right Considerations On IPR related issues, Nokia refers to its statement on patent licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA. 7. Acknowledgements Authors of the document would like to thank Jari Malinen for his assistance. References [1] Weinmiller, J., Schlager, M., Festag, A., Wolisz, A. Performance Study of Access Control in Wireless LANs IEEE802.11 DWFMAC and ETSI RES 10 HIPERLAN. Mobile Networks and Applications, vol. 2, Number 1, pp.55-57, 1997. Authors' Addresses C edric Westphal Charles Perkins Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1 650 625-2247 Phone: +1 650 625-2986 EMail: Cedric.Westphal@Nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Westphal, Perkins Expires August 2002 [Page 8] Internet Draft Piggyback performance February 2002 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Westphal, Perkins Expires August 2002 [Page 9]