idnits 2.17.1 draft-westphal-mobileip-piggyback-bu-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 327 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Cedric Westphal 2 Internet Draft Charles Perkins 3 Expires: August 2002 Nokia Research Center 4 Informational February 2002 6 Some Heuristics about Piggybacked Binding Updates 7 draft-westphal-mobileip-piggyback-bu-00.txt 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at 19 any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at: 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at: 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document presents some simple analytical results with respect to 30 the performance improvement brought by piggybacking binding updates 31 (BUs). We see that the improvement in term of bandwidth is not 32 significant unless the mobile terminal sending BUs moves very fast. 33 We also see on the other hand that the improvement in term of jitter 34 is quite significant in most situations. 36 Contents 38 Status of This Memo 1 40 Abstract 1 42 1. Introduction 2 44 2. Assumptions 3 46 3. Bandwidth Gain Using Piggybacking 3 47 3.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3.2. Some numerical examples . . . . . . . . . . . . . . . . . 4 49 3.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 5 51 4. Jitter Induced by Piggybacking 5 52 4.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4.2. Numerical values . . . . . . . . . . . . . . . . . . . . 6 54 4.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Conclusion 8 58 6. Intellectual Property Right Considerations 8 60 7. Acknowledgements 8 62 Authors' Addresses 8 64 Full Copyright Statement 9 66 1. Introduction 68 In this short document, we present some analytical intuition with 69 respect to piggybacking. Piggybacking is the insertion of a binding 70 update (BU) into a regular payload packet sent from the mobile node 71 (MN) to the correspondent node. Attaching the BU to a packet that 72 goes to the same destination saves the MN from sending a BU in a 73 separate packets, and optimizes the resource. In this document, we 74 investigate how much bandwidth is economized this way, and how jitter 75 is reduced. 77 2. Assumptions 79 We consider a MN talking to a CN. The MN is connected to an access 80 router (AR) via a bandwidth constrained wireless link. We consider 81 the bandwidth consumed on this link with and without the use of 82 piggybacking. A BU is sent, via piggybacking or independently, 83 every time the MN moves away from a cell, and changes access router, 84 or every time the life time of the BU expires. We assume that the 85 time spent at the AR by the MN is T_cell . This is the time spent 86 in one cell before the MN moves to the next cell. We denote by 87 T_lt the life time of a BU. MN sends packets to the CN in a stream. 88 Piggybacking applies only to stream, as it needs a payload packet 89 as a carrier to transport the BU. Isolated packets do not need to 90 update the CN about the movement of the MN. We denote by T_flow 91 the time length of a connection or packet stream. We denote by Pi 92 the packet rate within this stream and by s the packet size of the 93 packets within this stream. We are considering the long term effects 94 of piggybacking in terms of bandwidth. This means that, as the 95 bandwidth use and the BU count are additive quantities, we only need 96 to consider the deterministic mean values of T_cell ,Pi, s or T_flow 97 . We denote by H_bu the size of an independent BU, H_ip the size of 98 a IP header, and h = H_bu + H_ip the added size to a payload packet 99 by piggybacking. 101 3. Bandwidth Gain Using Piggybacking 103 3.1. Analysis 105 We define the BU rate to be: 106 lamba_bu = max (1/T_cell,1/T_lt) (1) 107 The bandwidth B_pb use with piggybacking and B_wo without are, per 108 flow: 109 B_pb = T_flow ((s +H_ip )Pi + h lamba_bu ) 110 Bwo = T_flow ((s +H_ip )Pi + H_bu lamba_bu ) 111 and the improvement ratio r_pb is given by (B_pb/B_wo): 113 B_pb (s+H_ip)Pi + h lambda_bu 114 r_pb = ---- = ----------------------------- 115 B_wo (s+H_ip)Pi + H_bu lambda_bu 117 h 1 - h/H_bu 118 = ---- + -------------------------------- (2) 119 H_bu 1 + lambda_bu (H_bu/Pi(s+H_ip)) 121 This last quantity decreases from 1 for lamba_bu = 0 to (h/H_bu) as 122 lamba_bu grows to infinity. The inflexion point (or cutoff value as 123 this diagram is that of a lowpass filter plus some fixed gain) in the 124 Bode diagram is for 126 (s+H_ip)Pi 127 lamba_bu = ------------- (3) 128 H_bu 130 and achieves a ratio 131 r_pb = 0.66 (4) We plot the Bode diagram in Figure 1. 133 1 |-------- 134 | \ 135 | \ 136 | \ 137 | \ 138 | \ 139 | `----------- 140 .33+--------------------------- 141 .01 1 100 10000 143 Fig. 1. Lowpass filter 145 3.2. Some numerical examples 147 If we assume some typical values for VoIPv6 streams, h = 30 bytes, 148 including authentication option, H_bu = 90 bytes, H_ip = 40, Pi = 149 1/20 ms^(-1) , and s = 20 bytes. 150 The best possible achievable ratio is thus h/H_bu = 0.33, if the BU 151 rate is infinite. 152 The worst possible ratio is attained for the minimal value of 153 lamba_bu = 1/T_lt . T_lt is typically of the order of 60 s, which 154 yields a ratio r_pb = 0.9999. 155 The cutoff value is: 157 (s +H_ip )Pi 158 lamba_bu = --------------------- = 33 BU per second (5) 159 H_bu 161 For lambda_bu equal to 1 BU per second, we attain r_pb = 0.98, for 162 lambda_bu equal to 10 BU per second (one BU every 100 ms), r_pb is 163 about 80%. 165 For these values of the parameter, a significant gain is achieved for 166 more than one BU per second. Note that the assumption is of one BU 167 per flow to the CN. If a MN has several flows to the same CN, then, 168 as far as average bandwidth is concerned, they can be aggregated into 169 one single flow with larger packet size s. The larger the packet 170 size, the smaller the gain from piggybacking. 172 3.3. Conclusion 174 Piggybacking has an impact of 0.2% for one BU every 10s, 2% for a BU 175 every second and for small packet sizes (20 bytes). This means that: 177 - if VoIP in cellular network is the goal, there is no need for 178 piggybacking, as handoff frequency is in the order of the minute. 180 - if bigger packets are transmitted, for video streaming, then 181 there is no need for piggybacking either, as the packet size 182 increase cancels the increase in the BU frequency induced by 183 smaller cells 185 - if several streams are transmitted from the CN to the MN, then 186 there is less need for piggybacking either. 188 - for packets that do not belong to a stream, there is no use for 189 piggybacking. 191 - if LMM mechanism is used to reduce the frequency of the binding 192 updates, then it makes piggybacking less valuable. For instance, 193 BETH with a 5 hops tunnel brings a potential gain of 5% down 194 to 1%. item if Header Compression is applied, it reduces H_ip 195 adding to the value of piggybacking. However, H_bu most probably 196 can be compressed as well (at least static info is the same). 197 A decrease of H_bu from 90 to 60 bytes decreases the maximal 198 gain from 66% to 50% for infinite BU rate. For a BU rate of one 199 BU per second, if H_ip is compressed to 0 byte and H_bu to 60 200 bytes, then the achieved ratio is r_pb = 1 - 0.03, or a 3% saved 201 bandwidth, instead of 2%. The gain is not significant. 203 This is a very simple analysis. However, I think it is telling not 204 to go to war for piggybacking on the ground of bandwidth gain. 206 4. Jitter Induced by Piggybacking 208 4.1. Analysis 210 A quantity of interest affected by piggybacked BUs is the jitter 211 perceived by a stream of packets. Keeping the notations from section 212 II, and denoting by c the capacity per unit of time of the channel, 213 and t_a the time to access and to release the channel. In this 214 situation, the added delay between two packets from the same flow 215 caused by the BU is: 217 delta_wo = t_a + H_bu/c without piggybacked BUs 218 delta_pb = h/c with piggybacking (6) 220 This is the jitter only at a given link, note that this jitter can be 221 amplified by having several hops within the network. The relative 222 improvement with respect to jitter is thus: 224 delta_pb h 225 r_j = ------------- = -------------- (7) 226 delta_wo c t_a + H_bu 228 The minimum improvement, corresponding to the maximal value of r_j 229 , is for a link with no delay to access or release the channel, or 230 for links with little capacity. The maximum value is ( h/H_bu ). 231 For link with some delay to access or release the channel and large 232 capacity, the gain of piggybacking the BUs increases with the link 233 capacity c as r_j (c) decreases to 0. 235 4.2. Numerical values 237 We consider again the values h = 30, H_bu = 90. In a slow link 238 or when there is no delay to access the channel, namely t_a = 0, 239 piggybacking the BUs reduces the jitter created by the BU by a 240 factor 3. Assume the capacity to be 100 kbits per second. Not 241 piggybacking the BUs adds a delay delta_wo - delta_pb of 4.8 ms. 242 Assume the capacity to by 25 kbits per second, the extra delay of 243 sending a separate BU is about 20 ms. Assume now the time to release 244 and access the channel t_a to be 20 ms. Then for the capacity 100 245 kbits/s, the extra delay delta_wo - delta_pb is 25 ms, for the 246 capacity 25 kbits/s, the extra delay is 45 ms. The relative gain r_j 247 is 0.09 for c = 100 kbits : the jitter is reduced by more than 90 % 248 by piggybacking the BUs. For the capacity 25 kbits/s, the gain is an 249 80 % reduction of the jitter. 251 As for instance [1] and other references point out, an access delay 252 of 10 ms is a quite common occurrence. For a 2Mb/s station with 25 253 MNs, a 20 ms delay is attained for a total load of 1 Mb/s. As the 254 load increase to 1.5Mb/s, so does the delay to 40ms. A value of t a 255 equals to 40ms would mean the user would perceive this delay. Note 256 the system is loaded with 1.5Mb/s, but is far from being saturated. 257 Note that the throughput degrades, and thus c diminishes. However, 258 the delay (H_bu - h)/c is never significant with respect to t_a . 260 In figure 3, we present the additional delay induced by not 261 piggybacking. To obtain this delay, we extracted from [1] the time 262 to access the channel and added the time to transmit the H_bu- h over 263 the channel. Figure 3 plots the additional delay against the load 264 of the network. The load in the network varies from 0% to 100%, at 265 ms 266 50 | _______ 25 users 267 | / 268 45 | / 269 | / 270 40 | / 271 | | 272 35 | / 273 | / 274 30 | / 275 | / 276 25 | / 277 | | 278 20 | / _______ 8 users 279 | / / 280 15 | / / 281 | / /-/ 282 10 |----------- /-/ 283 | /-/ 284 5 | /---------/ 285 |<------------------------------ 2 users 286 0 +------------------------------- 287 0 10 20 30 40 50 60 70 80 90 100 load on the system 289 Figure 3: Added delay by not piggybacking the BUs wrt Link Congestion 291 which point the full capacity of the 2Mbps link is reached. The 292 actual throughput is lower of course. The delay is plotted for 2 293 users, 8 users and 25 users sharing this link. This situation is a 294 pretty common situation: piggybacking reduces on this link a jitter 295 that the user would otherwise perceived. 297 4.3. Conclusion 299 There is a significant gain in smoothing the jitter by piggybacking 300 the BUs, especially when either the bandwidth is constrained or the 301 acquisition time for the channel is long. Both situations being 302 quite common, this illustrate the need for piggybacking. 304 5. Conclusion 306 We have considered the impact of piggybacking the BUs over a single 307 link with respect to bandwidth and to jitter. In the former, the 308 gain requires a high rate of BUs to be significant. In the latter, 309 the gain is obvious for high channel acquisition times or in low 310 bandwidth links. In a tight link, the jitter is more significant, 311 as the link may not be able to recover from the variation in packet 312 arrival times, and the jitter translates into delay for subsequent 313 packets. 315 6. Intellectual Property Right Considerations 317 On IPR related issues, Nokia refers to its statement on patent 318 licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA. 320 7. Acknowledgements 322 Authors of the document would like to thank Jari Malinen for his 323 assistance. 325 References 327 [1] Weinmiller, J., Schlager, M., Festag, A., Wolisz, A. Performance 328 Study of Access Control in Wireless LANs IEEE802.11 DWFMAC and 329 ETSI RES 10 HIPERLAN. Mobile Networks and 330 Applications, vol. 2, Number 1, pp.55-57, 1997. 332 Authors' Addresses 334 C edric Westphal Charles Perkins 335 Communications Systems Lab Communications Systems Lab 336 Nokia Research Center Nokia Research Center 337 313 Fairchild Drive 313 Fairchild Drive 338 Mountain View, California 94043 Mountain View, California 94043 339 USA USA 340 Phone: +1 650 625-2247 Phone: +1 650 625-2986 341 EMail: Cedric.Westphal@Nokia.com EMail: charliep@iprg.nokia.com 342 Fax: +1 650 625-2502 Fax: +1 650 625-2502 344 Full Copyright Statement 346 Copyright (C) The Internet Society (2000). All Rights Reserved. 348 This document and translations of it may be copied and furnished to 349 others, and derivative works that comment on or otherwise explain it 350 or assist in its implementation may be prepared, copied, published 351 and distributed, in whole or in part, without restriction of any 352 kind, provided that the above copyright notice and this paragraph 353 are included on all such copies and derivative works. However, 354 this document itself may not be modified in any way, such as by 355 removing the copyright notice or references to the Internet Society 356 or other Internet organizations, except as needed for the purpose 357 of developing Internet standards in which case the procedures 358 for copyrights defined in the Internet Standards process must be 359 followed, or as required to translate it into languages other than 360 English. 362 The limited permissions granted above are perpetual and will not be 363 revoked by the Internet Society or its successors or assigns. 365 This document and the information contained herein is provided on an 366 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 367 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 368 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 369 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 370 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Acknowledgement 374 Funding for the RFC editor function is currently provided by the 375 Internet Society.