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]