Internet DRAFT - draft-westphal-mobileip-piggyback-bu

draft-westphal-mobileip-piggyback-bu




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]