1. 21-08-0xxx-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0206-00-0000 Title: An Implementation Report on MIH Fragmentation Date Submitted: July 11, 2008 Presented at: Authors or Source(s): Donald Baker (Telcordia) and Yoshihiro Ohba (Toshiba) Abstract: This document contains an implementation report for MIH fragmentation functionality

2. 21-08-0xxx-00-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 and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html

3. 21-08-0xxx-00-0000 Environment Two MIHFs on the same Windows XP PC run the MIH protocol using network socket CPU: Intel Pentium 4, Dual core 3.4 GHz Memory: 1.5G MIH Fragmentation : enabled MIH Acknowledgment: enabled Piggybacking ACK in response: disabled MIH Transport Protocol: UDP

4. 21-08-0xxx-00-0000 Conditions aFragmentationThreshold = fragment size (except for the last fragment) = 1500 octets Message retransmission timer timeout value: 3000 ms, though not relevant Number of fragments in a message: 1, 2, …, 20 To get larger fragments, an MIH_Get_Information request message was constructed with larger query strings Each data points represent 100 samples. No samples had dropped packets All times are milliseconds. All samples were collected in one execution of the program Sender and receiver are in the same address space which makes message transmit time negligible and may make "all packets sent" artificially low

5. 21-08-0xxx-00-0000 Measured Data Data is based on "linearizing" the overall send process and taking time samples at key points in the process: 1) When the stack client (at the sender) has a message and begins the send Message call 2) Just before the first send packet is put on the socket 3) Just before the last packet is put on the socket. 4) Just after the last packet is received. 5) Just before the receiver sends the ack 6) Just after the sender receives the ack 7) When the stack client has the send message call return (1)(2) (3) (4) (5)(6)(7) Sender Message Processing Sender All Packets Sent Last Packet Transit Time Receiver Assembly Time ACK Transit Time Sender ACK Processing Time Series1 Series2Series3 Series4 Series5 Series6

6. 21-08-0xxx-00-0000 Result (table view) Frags Original size Sender Message Processing (ms) Sender All Packets Sent (ms) Last Packet Transit Time (ms) Receiver Assembly (ms) Ack Transmit Time (ms) Sender Ack Processing (ms) Total Send Time (ms) 152440.77101.2081.19698.44134.67845.212301.47 22256354.24303.7427.311477.11202.70893.163258.27 33356331.02494.2126.301812.27225.63994.853884.29 44456399.94605.2038.312167.84251.52735.264198.08 56656521.29803.98187.173144.87297.61665.125620.04 67756694.83942.62162.913577.58314.65615.056307.63 78856774.881165.2311.513801.63317.06489.056559.34 811056946.481032.6641.594335.82328.78358.767044.10 912156983.391230.1834.624871.17344.30412.577876.24 10132561113.461379.7723.205376.56340.74503.908737.63 11154561175.061632.9530.005880.13340.20578.569636.89 12165561298.351675.4427.366851.11336.92534.1510723.34 13176561457.911811.9323.088433.57348.24520.7512595.48 14198561544.482343.4522.419463.00338.69806.2114518.25 15209561619.972401.9126.358903.53348.67417.7513718.17 16220561803.063093.37147.858818.59359.59366.2314588.70 17242561806.582773.4120.989776.37353.02388.2815118.65 18253561874.823131.4915.689568.93336.79357.0715284.79 19264561949.512458.3926.9210103.51356.371060.7015955.40 20286562091.692619.0451.8211608.66354.26368.5317094.00

7. 21-08-0xxx-00-0000 Result (graph view)

8. 21-08-0xxx-00-0000 Analysis The sender message processing time goes up linearly, as expected due to the time it takes to fragment ever larger messages The sender all packets sent also goes up linearly at about the same rate. The packet transmit time and ack transmit time are constant, as expected. The receiver assembly time is the dominating cost. It's possible that this cost could be reduced by changing the implementation to do less copying.  New result with changing the implementation will be available soon The sender ack processing cost is relatively high due to thread handoffs in the implementation.