1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN:21-06-0681-01-0000
Title: Congestion and Flow Control for MIH Protocol
Date Submitted: September 13, 2006
Presented at IEEE session in Melbourne
Authors or Source(s):
Yoshihiro Ohba and Subir Das
Abstract: This document proposes text for LB1 comment # 708.

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development

3. LB1 Comment #708 on Section 8.3.1
“The protocol does not seem to include any capability to react to or avoid congestion events except as provided by the underlying transport. In particular, there is no mechanism to prevent the initiation of large numbers of parallel transactions, and the retransmission timeout is not adaptive (there is no backoff). This may be acceptable for operation of the MIHF protocol between nodes which directly connected over a single link which has native overload control; however, it would not be an acceptable approach for operation over IP networks in which congestion in intermediate nodes is not visible. The lack of rate limitation and the non-adaptiveness of the retransmit timer means that the protocol has no way to avoid causing congestion events.”
Resolution of the WG: need text for such a comprehensive issue, see 32

4. Investigation of the issues
There are two issues indicated in the comment:
Issue #1: Prevention of a large number of retransmissions in a short time
Issue # 2: Prevention of a large number of transactions in parallel
Issue #1 is related to congestion control (controlling the flow of data during congestion)
can be solved with one of the two approaches:
TCP-style congestion control defined in RFC 2988
Retransmission timer is computed based on RTT measurement
DHCPv6-style congestion control defined in RFC 3315 (simpler than TCP-style one)
RT = IRT + RAND*IRT (IRT=initial retransmission time)
RT = 2*RTprev + RAND*RTprev (subsequent retransmission time)
if (RT > MRT) RT = MRT + RAND*MRT (MRT= maximum retransmission time)

5. Investigation of the issues
Issue #2 is related to flow control (controlling the flow of data)
Closed-loop flow control (i.e., flow control with explicit feedback on network congestion sent from receiving node) might be too heavy weight for MIH protocol as it is not a data plane protocol
Open-loop flow control might be sufficient for MIH protocol
DHCPv6 (RFC 4443) uses open-loop flow control with a single rate limiter (i.e., token bucket)
Limiting the average rate of transmission to N, where N can be either packets/second or a fraction of the attached link's bandwidth, but allowing up to B error messages to be transmitted in a burst, as long as the long-term average is not exceeded.
MIH protocol can follow the same approach

6. Observations
Congestion and flow control at MIH protocol layer should be turned off if provided by transport protocol
There is no need to mandate particular congestion and flow control schemes, but it might be good to have some recommended schemes

7. Recommendations Congestion control: DHCPv6-style
Flow control: token-bucket limiter (open-loop control)
See Congestion-and-Flow-Control.doc for proposed changes

8. Back-Up Slide

9. TCP-Style RT computation based on measured RTT
G: Clock granularity
When RTT is unknown:
RT = 3 with back-off rule applied to repeated retransmission
When the 1st RTT measurement R is obtained:
RT = SRTT + max (G, 4*RTTVAR) where
SRTT=R, RTTVAR = R/2
When subsequent RTT measurement R’ is obtained:
RT <- SRTT + max (G, 4*RTTVAR) where
RTTVAR = (1 – alpha) * RTTVAR + beta * |SRTT - R'|
SRTT = (1 - alpha) * SRTT + alpha * R‘
Recommended alpha=1/8, bete=1/4
If computed RT < 1, RT is rounded to 1
If computed RT > 60, a maximum value may be placed