Subject: [MOBILE-IP] RP Flow Control

From: Ajoy Singh <[email-masked]>
Date: Mon, 20 Mar 2000 14:31:56 -0600

Hello All,
Here is the initial draft of the flow control extension for RP
interface. Lately we have been doing some work and it seems, it is
useful to have flow control for RP interface. We would like to have your
comments and suggestion for improvement for the attached document.
regards,
ajoy

MOBILE IP WORKING GROUP                            Ajoy Singh
Internet Draft                                     Irafan Ali
Document: draft-singh-mobileip-fcext-00.txt        Sebastian Thalanany,
Category: Standard Track                           Motorola
Expires August 2000                                Umamaheswar Acahari Kakinada,
                                                   3 Com Corporation
                                                   Rohit Verma,
                                                   Deloitte Consulting

        Flow control extension to Mobile IP for 3G Wireless Networks
                <draft-singh-mobileip-fcext-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.

1. Abstract

   This draft proposes an extension to mobile IP as used in third
   generation wireless network [7,1,14] to provide a flow control
   mechanism on a per-session basis for data sent from the packet data
   servicing node (PDSN) to a radio network node (RNN). This extension
   solves the problem of significant performance degradation when
   packets are dropped at the RNN due to channel setup latency and rate
   mismatch between the air interface and link between the RNN and PDSN
   (RP link).

2. Conventions used in this document

2.1 Requirements keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [8].

Singh et. al,        RP Flow Control  August 2000                    1

                  draft-singh-mobileip-fcext-00.txt       August 2000

2.2 Terminology

     CDMA                  Code Division Multiple Access
     LZW                   Lempel-Ziv and Welch
     PDSN                  Packet Data Serving Node
     RNN                   Radio Network Node
     RP                    Interface between the RNN and the PDSN
     RF                    Radio Frequency

3. Introduction

   The high level architecture of a third generation cdma2000 network
   RP interface is shown in Figure 1 [7,1,14].

         +---------+            +---------+         +---------+
         |         |            |         |         |         |
         |   RNN   |----RP------|  PDSN   |---------|  HA     |
         |         | Interface  |         |         |         |
         +---------+            +---------+         +---------+
            /|\
             |  Visited Access                    Home Network
             |  Provider Network
             |
             |
            \|/
        +--------+
        | Mobile |
        | Node   |
        +--------+_

     Figure 1: The Third Generation cdma2000 Network RP Interface [7,1]

   In figure 1, GRE encapsulated link layer traffic is exchanged
   between a PDSN and a RNN. RNN buffers packets received from the PDSN
   when it is unable to schedule radio resources for transmitting the
   packets received from the PDSN.

   The RNN interacts with a mobile node over a low bandwidth RF link,
   while it interacts with a PDSN over a relatively high bandwidth
   wired link. This is likely to cause packet loss since the PDSN can
   transfer packets to the RNN at a higher rate than the rate at which
   the RNN can transfer these packets to the mobile node over the RF
   link. Additionally, buffer overflow may occur at the RRN as a result
   of the following reasons:

        Handoff signaling latency.
        Data transfer rate reduction as a result of RF link
        degradation.
        Scheduling latency in an overloaded system.

Singh et.al,         RP Flow Control August 2000                    2

                  draft-singh-mobileip-fcext-00.txt       August 2000

   The effects of packet losses are amplified when delta compression
   [2,3] algorithms are used to compress packet headers or LZW based
   payload compression [4,5] is used. The loss of one compressed packet
   results in a loss of a larger number of packets. Also, packets
   subsequent to a dropped packet at the RNN, which are not correctly
   decompressed by the mobile node, are transmitted on the air-
   interface. This results in wastage of precious air-interface
   bandwidth.

   Moreover, even in cases where no compression is used, the loss of
   one packet at the RNN could result in multiple PPP frames being
   dropped at the mobile node as multiple PPP frames could be
   encapsulated in a single GRE packet or the dropped GRE packet could
   contain a PPP frame boundary.

   The objective of the flow-control mechanism is to reduce the packet
   drops at the RNN. Packets could be buffered at the PDSN or dropped
   before the compression process at the PDSN. The utility of the
   proposed flow control mechanism is not limited to links carrying
   compressed traffic, it may also be used to enhance throughput for
   non-compressed traffic.

4. Mobile/IP and RP protocol Extensions

   This section describes extensions to Mobile/IP [9] and RP[7,1,14]
   protocol required to support flow control at RP interface within the
   third generation cdma2000 network.

4.1 Registration Request

   An RNN will send flow control extension as a part of a Registration
   Request message. The flow control extension SHOULD be attached by
   RNN as part of Registration Request to negotiate flow control with
   PDSN. The flow control extension should be attached after the
   session specific extension defined in the RP interface protocol
   [7,1,14]. The format of flow control is defined in section 4.2.

4.2. Flow Control Extension

   This extension is defined to carry information related to flow
   control for the session between a RNN and a PDSN across the RP
   interface. It should be a part of the Registration Request and Reply
   messages. The code field in the request message MUST be set to 1 for
   the peer to detect flow control support. If the recipient also
   supports this extension then the code is set to zero, else the code
   is set to a non-zero value.

Singh et.al,         RP Flow Control August 2000                    3

                  draft-singh-mobileip-fcext-00.txt       August 2000

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Length    | Code  |          PPD          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Receive Window Size                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Starting Tx Window Size                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The detailed format of the extension is shown as follows.

        Type            TBD.

        Length          This is one octet field and it indicates the
                        length (in bytes) of the extension, NOT
                        including the Type and Length fields.

        Code            1 in Request
                        0 in Reply if accepted
                        Non zero in reply if extension not acceptable.

        PPD             A measure of packet processing delay (PPD).
                        This value is specified in units of 1/10
                        seconds. For sliding window flow control, see
                        section 6.3 for a description of how this value
                        is determined and used. For ON-OFF flow
                        control, see Section 7.

        Receive Window Size This Indicates receive window size of
                        sender. In case the value set by the sender is
                        non-zero, then sliding window flow control is
                        being negotiated. In case the value is 0, then
                        ON-OFF flow control is being negotiated. Note
                        that a zero receive window size is not
                        appropriate for sliding window flow control. In
                        reply if code is non-zero this field is not
                        interpreted.

        Starting Tx Sequence Number Indicates starting transmit
                        sequence number. In reply if code is non-zero
                        this field is not interpreted.

   When a Registration Request is received by a PDSN, if the PDSN
   supports the flow control extension, it sets the expected receive
   sequence number to the Starting Tx sequence number of the extension.
   For sliding window flow control, the PDSN also

Singh et.al,         RP Flow Control August 2000                    4

                  draft-singh-mobileip-fcext-00.txt       August 2000

   sets the its transmit window size to the receive window size
   received in the flow control extension and uses the PPD value to as
   a seed to the adaptive algorithm to compute time-out value as
   specified in Section 6.3. For ON-OFF flow control, the PDSN uses PPD
   for the timeout value to avoid deadlock situation due to drop of ON
   signal from the receiver as specified in Section 7.

   To signal to the RNN that the PDSN supports flow control, a PDSN
   MUST set the Code to zero in the flow control extension of the
   Registration Reply message. When the flow control extension is NOT
   supported by PDSN, the extension (all fields) is copied to the
   Registration Reply without any changes. For sliding window flow
   control, the PDSN sets the receive window size to a non-zero value
   if flow-control is desired for data transfer from RNN to PDSN and to
   zero value if flow-control is not desired. For ON-OFF flow control
   the receive window size field is set to zero in the registration
   reply message. In either flow control schemes, the PDSN sets the
   starting Tx. sequence number and PPD field to appropriate values.

   When a Registration Reply is received by a RNN that has sent a
   Registration Request with flow control extension, the reply message
   MUST be processed as described in the following sentences. If the
   Registration Reply message does not contain the flow control
   extension or the Code field of the flow control extension is set to
   a non-zero value, the RNN will assume that the PDSN does not support
   flow control. Otherwise, based on the flow control mechanism being
   negotiated, the RNN uses the values in the different fields
   according to the logic specified above for PDSN.

4.3 Registration Reply

   The Registration Reply will be sent by a PDSN following the
   procedure as described in [7,1,14]. The PDSN shall attach a flow
   control extension with every Registration Reply message sent based
   on the procedure defined in Section 4.2, when the received
   Registration Request message contains a flow control extension. PDSN
   MAY accept or reject proposed flow control by setting appropriate
   code field of flow control extension as defined in Section 4.2.

5. GRE Extension

   The GRE header suggested in [10] is modified to add acknowledgement
   field, which will be used for sending explicit, or piggybacked
   acknowledgement of received GRE packet.

Singh et.al,         RP Flow Control August 2000                    5

                  draft-singh-mobileip-fcext-00.txt       August 2000

   The proposed GRE header will have the following format

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S|F| Reserved        |Ver  |        Protocol Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |       Reserved (Optional)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Tx Sequence Number (Optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         ON-OFF Signal/Ack Sequence Number (Optional)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Key Present (bit 2)

        If the Key Present bit is set to 1, it indicates that the Key
        field is present in the GRE header. Otherwise, the Key field is
        not present in the GRE header.

   Tx Sequence Number Present (bit 3)

        If the Tx Sequence Number Present bit is set to 1, then it
        indicates that the Sequence Number field is present.
        This field MUST be set to support sliding Window based flow
        control.

   Flow Control Present (bit 4)

        If the Flow Control Present is bit set to 1, it indicates that
        the ON-OFF signal/Ack sequence number field is present.

   Key Field (4 octets)

        The Key Field contains a four octet number, which was inserted
        by the encapsulator. The key field will be used to send Session
        id of the RP session.

   Sequence Number (4 octets)

        Contains sequence number of the payload.

   ON-OFF Signal/Ack Sequence Number (4 octets)

        If sliding window flow control used, this field contains the
        sequence number of the highest numbered GRE packet received by

Singh et.al,         RP Flow Control August 2000                    6

                  draft-singh-mobileip-fcext-00.txt       August 2000

        the sending peer for this user session. If ON-OFF flow control
        is used, a non-zero value in this field is an OFF signal and a
        zero value is a ON signal from the receiver to the sender.

6.  Sliding Window Flow Control Mechanism

   This document proposes a sliding window protocol to provide flow
   control between a PDSN and an RNN. The main purpose of the sliding
   window protocol is to provide flow control. The tunnel peers do not
   perform packet retransmissions. Note: The sliding window mechanism
   provided here is identical to PPTP RFC [11]. Any recommendations on
   an improved sliding window mechanism are welcome.

6.1. Sliding Window Protocol

   The sliding window protocol used on the RP data path is used for
   flow control by the RP tunnel peers involved in packet transfers.
   The enhanced GRE protocol allows packet acknowledgments to be
   piggybacked on data packets. Acknowledgments can also be sent
   separate from data packets. The main purpose of the sliding window
   protocol is for flow control and the RP tunnel peers do not perform
   retransmissions.

6.1.1.  Initial Window Size

   Although each side has indicated (section 7) the maximum size of its
   receive window, it is recommended that a conservative approach be
   taken while starting a packet transfer. The initial window size on
   the transmitter is set to half the maximum size the receiver
   requested, with a minimum size of one packet. The transmitter stops
   sending packets when the number of packets awaiting acknowledgment
   is equal to the current window size.  As the receiver successfully
   digests each window, the window size on the transmitter is bumped up
   by one packet until the maximum is reached.  This method prevents a
   system from flooding an already congested network in the absence of
   history information.

6.1.2. Closing the Window

   When a time-out does occur on a packet transfer, the sender adjusts
   the size of the transmit window down to one half of it's value when
   it failed. Fractions are rounded up, and the minimum window size is
   one.

6.1.3 Opening the Window

   With every successful transmission of a window's worth of packet
   without a time-out, the transmit window size is increased by one

Singh et.al,         RP Flow Control August 2000                    7

                  draft-singh-mobileip-fcext-00.txt       August 2000

   packet until it reaches the maximum window size that was sent by the
   other side, when the call was connected.  As stated earlier, no
   retransmission is done on a time-out. After a time-out, the
   transmission resumes with the window starting at one half the size
   of the transmit window when the time-out occurred and adjusting
   upward by one each time the transmit window is filled with packets
   that are all acknowledged without time-outs.

6.1.3. Window Overflow

   When a receiver's window overflows with too many incoming packets,
   excess packets are thrown away. This situation should not arise if
   the sliding window procedures are being properly followed by the
   transmitter and receiver. It is assumed that, on the transmit side,
   packets are buffered for transmission and are no longer accepted
   from the packet source when the transmit buffer fills.

6.1.4. Multi-packet Acknowledgment

   One feature of the RP sliding window protocol is that it allows the
   acknowledgment of multiple packets with a single acknowledgment. All
   outstanding packets with a sequence number lower or equal to the
   acknowledgment number are considered acknowledged. Time-out
   calculations are performed using the time the packet corresponding
   to the highest sequence number being acknowledged was transmitted.
   Adaptive time-out calculations are only performed when an
   acknowledgment is received.  When multi-packet acknowledgments are
   used, the overhead of the adaptive time-out algorithm is reduced.
   The RNN is not required to transmit multi-packet acknowledgments.
   The RNN can instead acknowledge each packet individually as it is
   delivered to the higher layer.

6.2.  Out-of-sequence Packets

   Occasionally packets may lose their sequencing across a complicated
   internetwork. For instance, a PDSN may send packets 0 to 5 to a RNN.
   As a result of rerouting in the internetwork, packet 4 may arrive at
   the RNN before packet 3. The RNN acknowledges packet 4, and may
   assume that packet 3 is lost. This acknowledgment grants window
   credit beyond packet 4.

   When the RNN does receive packet 3, it MUST not attempt to transmit
   it to the corresponding higher layer.  To do so could cause
   problems, as proper PPP or any serial interface protocol operation
   is based upon receiving packets in sequence.  PPP properly deals
   with the loss of packets, but not with reordering. Therefore, out of
   sequence packets between the PDSN and RNN MUST be silently
   discarded, or they may be reordered by the receiver.  When packet 5
   comes in, it is acknowledged by the RNN since it has a higher
   sequence number than 4, which was the last highest packet
   acknowledged by the RNN.  Packets with duplicate sequence numbers
   should never occur since the RNN and PDSN never retransmit GRE

Singh et.al,         RP Flow Control August 2000                    8

                  draft-singh-mobileip-fcext-00.txt       August 2000

   packets. A robust implementation will silently discard duplicate GRE
   packets, if any are received.

6.3 Acknowledgment Time-Outs

   The RP protocol uses sliding windows and time-outs to provide both
   user session flow-control across the internetwork and to perform
   efficient data buffering to keep the RNN-PDSN data channels full
   without causing receive buffer overflow. RP protocol requires that a
   time-out be used to recover from dropped data or acknowledgment
   packets. The implementation of the time-out is vendor-specific. It
   is suggested that an adaptive time-out be implemented with backoff
   for congestion control.

   The time-out mechanism proposed here has the following properties:

   Independent time-outs for each session. A device (RNN or PDSN) will
   have to maintain and calculate time-outs for every active session.
   An administrator-adjustable maximum time-out, MaxTimeOut, unique to
   each device.

   An adaptive time-out mechanism that compensates for changing
   throughput. To reduce packet-processing overhead, vendors may choose
   not to recompute the adaptive time-out for every received
   acknowledgment.  The result of this overhead reduction is that the
   time-out will not respond as quickly to rapid network changes.
   Timer backoff on time-out to reduce congestion. The backed-off timer
   value is limited by the configurable maximum time-out value. Timer
   backoff is done every time an acknowledgment time-out occurs. In
   general, this mechanism has the desirable behavior of quickly
   backing off upon a time-out, and of slowly decreasing the time-out
   value as packets are delivered without time-outs.

Some definitions:

   Packet Processing Delay (PPD) is the amount of time required for
   each side to process the maximum amount of data buffered in their
   receive packet sliding window. The PPD is the value exchanged
   between the RNN and PDSN when a call is established. For the PDSN,
   this number should be small.  For a RNN making RF connections, this
   number could be significant.

   Sample is the actual amount of time incurred receiving an
   acknowledgment for a packet. The Sample is measured, not calculated.

   Round-Trip Time (RTT) is the estimated round-trip time for an
   Acknowledgment to be received for a given transmitted packet. When
   the network link is a local network, this delay will be minimal (if
   not zero). When the network link is the Internet, this delay could
   be substantial and vary widely. RTT is adaptive: it will adjust to
   include the PPD and whatever shifting network delays contribute to
   the time between a packet being transmitted and receiving its

Singh et.al,         RP Flow Control August 2000                    9

                  draft-singh-mobileip-fcext-00.txt       August 2000

   acknowledgement.

   Adaptive Time-Out (ATO) is the time that must elapse before an
   acknowledgment is considered lost.  After a time-out, the sliding
   window is partially closed and the ATO is backed off.

   The Packet Processing Delay (PPD) parameter is a 12-bit value
   exchanged during the Call Control phase that represents tenths of a
   second (64 means 6.4 seconds). The protocol only specifies that the
   parameter is exchanged, it does not specify how it is calculated.
   The determination of PPD values is implementation-dependent, and
   need not be variable (static time-outs are allowed). The PPD must be
   exchanged in the call connect sequences, even if it remains constant
   in an implementation. One possible way to calculate the PPD is:

   PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate

   Where,

   Header is the total size of the IP and GRE headers. MTU is the
   overall MTU for the internetwork link between the RNN and PDSN.

   WindowSize represents the number of packets in the sliding window,
   and is implementation-dependent. The latency of the internetwork
   could be used to pick a window size sufficient to keep the current
   session's pipe full. The constant 8 converts octets to bits
   (assuming ConnectRate is in bits per second). If the ConnectRate is
   in bytes per second, omit the 8. The value of PPD is used to seed
   the adaptive algorithm with the initial RTT[n-1] value.

6.3.1.  Calculating Adaptive Acknowledgment Time-Out

   The time-out allocated for the receipt of an acknowledgement is to
   be determined. If the time-out is set too high, the wait may be
   unnecessarily long for dropped packets. If the time-out is too
   short, the time-out may occur just before an acknowledgment arrives.
   The acknowledgement time-out should be reasonable and responsive to
   changing network conditions. The suggested adaptive algorithm
   described below is based on the TCP 1989 implementation and is
   explained in [11].  'n' means this iteration of the calculation, and
   'n-1' refers to values from the last calculation.

         DIFF[n] = SAMPLE[n] - RTT[n-1]
         DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
         RTT[n] = RTT[n-1] + (alpha * DIFF[n])
         ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
                  (chi * DEV[n]), MaxTimeOut))

   DIFF represents the error between the last estimated round-trip
   time and the measured time. DIFF is calculated on each iteration.

Singh et.al,         RP Flow Control August 2000                   10

                  draft-singh-mobileip-fcext-00.txt       August 2000

   DEV is the estimated mean deviation. This approximates the standard
   deviation. DEV is calculated on each iteration and stored for use in
   the next iteration. Initially, it is set to 0.

   RTT is the estimated round-trip time of an average packet. RTT is
   calculated on each iteration and stored for use in the next
   iteration. Initially, it is set to PPD.

   ATO is the adaptive time-out for the next transmitted packet. ATO is
   calculated on each iteration.  Its value is limited, by the MIN
   function, to be a maximum of the configured MaxTimeOut value.

   Alpha is the gain for the average and is typically 1/8 (0.125).

   Beta is the gain for the deviation and is typically 1/4 (0.250).

   Chi is the gain for the time-out and is typically set to 4.

   To eliminate division operations for fractional gain elements, the
   entire set of equations can be scaled. With the suggested gain
   constants, they should be scaled by 8 to eliminate all division. To
   simplify calculations, all gain values are kept to powers of two so
   that shift operations can be used in place of multiplication or
   division.

6.3.2. Congestion Control: Adjusting for Time-Out

   This section describes how the calculation of ATO is modified in the
   case where a time-out does occur.  When a time-out occurs, the time-
   out value should be adjusted rapidly upward.  Although the GRE
   packets are not retransmitted when a time-out occurs, the time-out
   should be adjusted up toward a maximum limit.  To compensate for
   shifting internetwork time delays, a strategy must be employed to
   increase the time-out when it expires (notice that in addition to
   increasing the time-out, we are also shrinking the size of the
   window as described in the next section).  For an interval in which
   a time-out occurs, the new  ATO is calculated as:

        RTT[n] = delta * RTT[n-1]
        DEV[n] = DEV[n-1]
        ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
                (chi * DEV[n]), MaxTimeOut))

   In this calculation of ATO, only the two values, that contribute to
   ATO and are stored for the next iteration, are calculated.  RTT is
   scaled by delta, and DEV is unmodified.  DIFF is not carried forward
   and is not used in this scenario.  A value of 2 for Delta, the time-
   out gain factor for RTT, is suggested.

Singh et.al,         RP Flow Control August 2000                   11

                  draft-singh-mobileip-fcext-00.txt       August 2000

7.ON-OFF Flow Control Mechanism

   In an ON-OFF flow control scheme, the receiver on detecting
   congestion event sends an explicit OFF signal to the sender to stop
   transmitting packets of a particular session. Once the receiver is
   ready to receive additional packets, it sends an ON signal event to
   the sender to restart transmission of a session's packet. The
   congestion event could be any receiver-defined event such as the
   average length of buffer dedicated to a flow reaching a high
   watermark. The congestion clearance signal, in such a case, would be
   the average queue length below a low watermark.

   ON-OFF flow control is simpler than sliding window flow control in
   the following manner:

   1.The receiver does not need to send explicit/piggybacked
   acknowledgement of the received packets. While sequence numbering is
   not needed for flow control, it could still be used to re-order out-
   of-sequence packets at the receiver.

   2.The logic at the sender and receiver is simpler in an ON-OFF flow
   control scheme.

   3.The bandwidth for feedback signaling is lower. Sliding window flow
   control requires constant updating of the ack sequence number,
   whereas in ON-OFF flow control, the receiver only sends an OFF or ON
   signal on detection/clearance of congestion conditions.

   However, ON-OFF flow control provides coarser flow control than
   sliding window flow control. In certain situations, such as when the
   tunneling end-points are not many hops away, ON-OFF flow control may
   be adequate.

   The extensions to Mobile IP protocol presented in Section 4 and 5
   enable either sliding window flow control or ON-OFF flow control to
   be used. As stated in Section 4.2, if the Receive window size field
   in a flow control extension message is set to zero (0), then ON-OFF
   flow control is being negotiated.

   Once an RP session has been opened, the sender MAY start
   transmitting packets in the GRE tunnel. The receiver is NOT REQUIRED
   to transmit an explicit ON signal to the sender.

7.1 Receiver's Logic

   On detecting a congestion event, the receiver transmits one or more
   OF signal to the sender. On the clearance of a congestion event, the
   sender sends one or more ON signal. The ON/OFF signal could be sent
   as a separate GRE packet or piggybacked onto data packets.

   It is RECOMMENDED that the detection of congestion/congestion-

 Singh et.al,         RP Flow Control August 2000                   12

                  draft-singh-mobileip-fcext-00.txt       August 2000

   clearance events at the receiver be based on averaged values rather
   than on instantaneous values for graceful operation.

   In the registration request message, the receiver informs the sender
   of the approximate time it takes for a congestion event to be
   cleared at the receiver in the PPD field of the flow control
   extension. Setting PPD to a low value could result in the sender
   sending packets to the receiver before a congestion is cleared,
   leading to packet drops at the receiver. Setting the PPD to a high
   value could result in the sender taking much longer to resume
   transmission of packets in case a ON signal is dropped by a network,
   resulting in lower throughput.

   As an OPTION, during congestion conditions, the receiver could
   periodically transmit OFF signals to the transmitter every alpha*PPD
   (alpha < 1.0) time units.

7.2 Sender's Logic

   On receiving an OFF signal from the receiver, the sender stops
   transmission of the tunneled session's packets. It should also start
   a timer on receipt of every OFF signal. The timeout value of the
   timer MUST be set to the value of PPD field flow control extension
   of the registration request message. On receipt of an ON signal or
   the expiration of the timer, the sender starts transmission of the
   tunneled session's packet.

   The timer is used at the sender to avoid a deadlock situation in
   case ON signals from the receiver are dropped in the network.

7.Security Considerations

   The flow control extension presented in this section will be used
   with base R-P interface protocol [7,1,14], so it will follow all the
   security measures supplied by R-P Interface protocol. No extra
   security measures are required to support flow control extension.

8.IANA Consideration

   This document specifies one new extension to Mobile IP protocol [9].
   The flow control Specific Extension defined in section 6 MUST be
   assigned the Type value of TBD.

9. References

   [1] 3GPP2 TSG-A,"3GPP2 Access Network Interfaces Technical
        Specification (3G-IOS)", Version 4.0.0, December 13 1999.

   [2] Jacobson, V., "Compressing TCP/IP Headers for low speed Serial
      links," RFC 1144, February 1990.

Singh et.al,         RP Flow Control August 2000                   13

                  draft-singh-mobileip-fcext-00.txt       August 2000

   [3] M. Degermark, B. Nordgren, S.Pink. "IP Header Compression",
   February 1999.

   [4] Pall, G., "Microsoft Point to Point Compression (MPPC)
   Protocol", RFC 2118, March 1997.

   [5] Friend, Simpson, "PPP LZS-DCP Compression Protocol (LZS-DCP),"
   RFC 1867, August 1996.

   [6] Hank, S., Li R., Farinacci, D., and P. Traina, "Generic Routing
   Encapsulation (GRE)", RFC 1701, October 1994.

   [7] Yong Chang, et. al, "Mobile IP Based Micro Mobility Management
   Protocol in The Third Generation Wireless Network", draft-ietf-
   mobileip-ext-02.txt

   [8] Brander, S., "Key words for use in RFCS to indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

   [9] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October
   1996.

   [10] Gopal Dommety, "Key and Sequence Number Extensions to GRE",
     draft-dommety-gre-ext-00.txt

   [11] K. Hamzeh, "Point to point tunneling Protocol", RFC 2637, July
   1999.

   [12] Stevens, R, "TCP/IP Illustrated Volume 1", p. 300, Addison
   Wesley, 1994.

   [13] Postel, J.,"Transmission Control Protocol", STD 7, RFC 793,
   Sept 1981.

   [14] TR 45.6,"Wireless IP Network standards", Jan 13 2000.

12. Acknowledgments

   The authors of this draft would like to thank author of PPTP
   informational RFC 2637. This draft uses windowing mechanism proposed
   in PPTP RFC. The authors of this draft would like to thank Shreesha
   Ramana for valuable comments and review of this draft.

11. Author's Addresses

   Ajoy Singh
   Motorola
   1501 West Shure Driver
   Arlington Heights, IL- 60004
   Phone: 847-632 6941
   Email: [email-masked]

Singh et.al,         RP Flow Control August 2000                   14

                  draft-singh-mobileip-fcext-00.txt       August 2000

   Irfan Ali
   Motorola
   1501 West Shure Driver
   Arlington Heights, IL- 60004
   Phone: 1-847-632-3281
   Email: [email-masked]

   Sebastian Thalanany
   Motorola
   1475 West Shure Drive
   Arlington Heights, IL - 60004
   Phone: (847) 435-9296
   Email: [email-masked]

   Umamaheswar A, Kakinand
   3Com Corporation,
   1800 West Central Road,
   Mount Prospect, IL -60056
   Email: [email-masked]

   Rohit Verma
   180, N. Stetson Ave.
   Chicago, IL 60601
   Email: [email-masked]

   Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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.

Singh et.al,         RP Flow Control August 2000                   15

Singh et.al,         RP Flow Control August 2000                   16

---

From: Pete McCann <[email-masked]>
Date: Thu, 23 Mar 2000 10:09:20 -0600

Hi, Ajoy,

Is there any convincing evidence (simulation results, analysis) that
says flow control is really needed over the R-P interface?  In the
absence of such evidence I am really skeptical about putting such
details in - remember the whole debacle that L2TP got into with flow
control (it was eventually removed from L2TP).

I would hope that any congestion can be taken care of by higher-layer
backoff or admission control mechanisms.  Adding flow control to R-P
really adds a lot of complexity that I think is unnecessary and will
slow down standardization and deployment of RNNs and PDSNs.  Also, if
the R-P interface ever evolves to carry IP packets instead of the
octet stream for PPP, the flow control will be quite redundant.

If you really think that some kind of flow control is necessary then
you can always put a buffer in the RNN, since the wireless physical
link is really terminated there (in fact there is such a buffer
already in the RNN for RLP).  I don't think propagating the flow
control back to the PDSN makes sense.

-Pete

Ajoy Singh <[email-masked]> (AS) writes:

AS> Hello All,
AS> Here is the initial draft of the flow control extension for RP
AS> interface. Lately we have been doing some work and it seems, it is
AS> useful to have flow control for RP interface. We would like to have your
AS> comments and suggestion for improvement for the attached document.
AS> regards,

---

From: Ajoy Singh <[email-masked]>
Date: Thu, 23 Mar 2000 11:43:39 -0600

Hello Pete,
Thanks for your reply. Please read the embedded reply.
regards,
ajoy

> control (it was eventually removed from L2TP).

I do not have any simulation results with me that i can send to you. But we have
observed this problem in prototype 3G system and we have alleviated this by
using  ON/OFF based flow control mechanism.  The main idea of this draft is to
provide PDSN with some feedback mechanism which can be used to drop packets
before doing any compression. This is usefull for payload and header compression
case. Moreover we are trying to say this is a optional feature and which can be
used in case we need to support PPP type of  payload/header compression
otherwise do not need to bother about flow control.

> backoff or admission control mechanisms.
>

BTW congestion control mechanism of TCP is also being challenged in case of
wireless link.

|Adding flow control to R-P really adds a lot of complexity that I think is
unnecessary and will
| slow down standardization and deployment of RNNs and PDSNs.

Yes adding sliding window flow control apprach might add complexity but adding
ON/OFF flow control seems to be very simple to implement.  Moreover suggested
flow control mechanism is optional feature and i do not see how this is going to
complicate implementation of RP interface.

|Also, if the R-P interface ever evolves to carry IP packets instead of the
|octet stream for PPP, the flow control will be quite redundant.

I do no know about any such plan, so i would rather not comment about this. But
are you talking to use SLIP like mechanism ?  If we assume RF link  same as
serial link we can use existing compression mechanism in this case ?  Comments ?

> control back to the PDSN makes sense.

I do not believe that any congestion can be taken care by providng buffering.
Buffering delays the congestion does not fix it , unless end to end feedback
mechanism is povided.  Comments ?

---

From: Pete McCann <[email-masked]>
Date: Thu, 23 Mar 2000 13:50:38 -0600

Hi, Ajoy,

A few comments below.

Ajoy Singh <[email-masked]> (AS) writes:

AS> I do not have any simulation results with me that i can send to
AS> you. But we have observed this problem in prototype 3G system and
AS> we have alleviated this by using ON/OFF based flow control
AS> mechanism.  The main idea of this draft is to provide PDSN with
AS> some feedback mechanism which can be used to drop packets before
AS> doing any compression. This is usefull for payload and header
AS> compression case. Moreover we are trying to say this is a optional
AS> feature and which can be used in case we need to support PPP type
AS> of payload/header compression otherwise do not need to bother
AS> about flow control.

Are you familiar with the role of RLP (the Radio Link Protocol) in a
cellular network?  It seems to me that you are duplicating some of
that functionality.  Did your prototype system take RLP into account?
Did it employ TCP-level flow control?

>> backoff or admission control mechanisms.

AS> BTW congestion control mechanism of TCP is also being challenged
AS> in case of wireless link.

Yes, but only because TCP confuses packet loss with congestion.  If we
have RLP to fix the packet loss, then TCP can handle congestion
end-to-end.

>> Adding flow control to R-P really adds a lot of complexity that I
>> think is unnecessary and will slow down standardization and
>> deployment of RNNs and PDSNs.

AS> Yes adding sliding window flow control apprach might add
AS> complexity but adding ON/OFF flow control seems to be very simple
AS> to implement.  Moreover suggested flow control mechanism is
AS> optional feature and i do not see how this is going to complicate
AS> implementation of RP interface.

Well, even though it would be optional depending on the connection
type you are still requiring vendors to implement and support it.
There will be a delay both in standardization and implementation.

>> Also, if the R-P interface ever evolves to carry IP packets instead of the

AS> I do no know about any such plan, so i would rather not comment
AS> about this. But are you talking to use SLIP like mechanism ?  If
AS> we assume RF link same as serial link we can use existing
AS> compression mechanism in this case ?  Comments ?

I was talking about one potential evolution step for 3G wireless data
that was discussed during development of the R-P interface document.
Right now the R-P interface is assumed to carry the PPP octet stream,
but it is flexible enough to carry encapsulated IP packets in the
future.  In that case the data link would be terminated in the RNN and
there would be no need to do the kind of buffering and flow control
you are talking about - the whole network between the RNN and PDSN
would be (encapsulated) IP traffic.  IP does not have or need flow
control between routers.

>> control back to the PDSN makes sense.

AS> I do not believe that any congestion can be taken care by providng
AS> buffering.  Buffering delays the congestion does not fix it ,
AS> unless end to end feedback mechanism is povided.  Comments ?

Exactly my point - you are not doing end-to-end flow control either.
You are stopping in the PDSN, which means (I assume) that packets are
buffered there until the RNN tells the PDSN it's OK to transmit them.
This buffer can overflow as well unless there is a truly end-to-end
congestion control scheme - that scheme today is TCP and in the future
(for voice-over-IP) it is admission control based on RSVP or some
other request/response protocol.  The R-P link is just one hop in a
larger end-to-end picture.

-Pete

---

From: Ajoy Singh <[email-masked]>
Date: Thu, 23 Mar 2000 17:22:52 -0600

Pete,
Please see the embedded reply.
regards,
ajoy

> Did it employ TCP-level flow control?

Matter of fact i have implemented IS-707 RLP code. So i do not know what RLP has
to do with this contribution. We are just arguing about some thing different.
The point here is to move congestion from RNN to PDSN so that RNN does not need
to build such mechanism of discarding packets. Just treat RF link as serial link
rather any anything else.  You might be aware that in case of modem some flow
control is built in modem and RAS drops packets before sending to modem.
Comments ?

> There will be a delay both in standardization and implementation.

This will work even if PDSN does not support flow control as RNN does not do flow
control when it does not receive flow control extension in Registration Reply
message.

> larger end-to-end picture.

I think i have talked about this in my previous replies.

---

From: Ajoy Singh <[email-masked]>
Date: Thu, 23 Mar 2000 17:40:24 -0600

> would be (encapsulated) IP traffic.  IP does not have or need flow
Let us talk about the current problem. You are absolutely right when thing changes
some of this will not make much sense.