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 802.21 session in Melbourne Authors or Source(s): Yoshihiro Ohba and Subir Das Abstract: This document proposes text for LB1 comment # 708. 21-06-0681-01-0000

IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 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 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>  21-06-0681-01-0000

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 21-06-0681-01-0000

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) 21-06-0681-01-0000

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 21-06-0681-01-0000

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 21-06-0681-01-0000

Recommendations Congestion control: DHCPv6-style Flow control: token-bucket limiter (open-loop control) See 21-06-0681-Congestion-and-Flow-Control.doc for proposed changes 21-06-0681-01-0000

Back-Up Slide 21-06-0681-01-0000

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 21-06-0681-01-0000