IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-08-0206-01-0000
Title: An Implementation Report on MIH Fragmentation
Date Submitted: July 15, 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
21-08-0206-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-08-0206-01-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
21-08-0206-01-0000
Conditions
• aFragmentationThreshold
= fragment size (except for the last fragment)
= 1500 octets
• Message retransmission timer timeout value: 3000 ms, though not relevant
• Reassembly timeout timer value: 1000ms
• 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
21-08-0206-01-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)
Series1 (2) Series2 (3)
Sender
Message
Processing
Sender
All Packets
Sent
21-08-0206-01-0000
Series3
Last Packet
Transit
Time
(4)
Series4 (5)
Receiver
Assembly
Time
Series5 (6)
ACK
Transit
Time
Series6 (7)
Sender ACK
Processing
Time
Result (table view)
Original
size
Frags
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)
1
52
0.22
0.00
0.17
0.77
0.13
0.87
2.17
2
2256
0.28
0.23
0.10
1.33
0.22
1.15
3.31
3
3356
0.35
0.39
0.10
1.39
0.23
0.87
3.32
4
4456
0.52
0.58
0.12
1.70
0.27
0.62
3.80
5
6656
0.62
0.80
0.10
2.03
0.29
0.62
4.46
6
7756
1.03
0.83
0.11
3.03
0.30
0.93
6.23
7
8856
0.98
0.94
0.09
2.17
0.33
0.43
4.94
8
11056
1.14
1.25
0.14
2.47
0.33
0.46
5.78
9
12156
1.25
1.31
0.10
2.32
0.34
0.45
5.76
10
13256
1.44
1.33
0.17
2.60
0.34
0.41
6.29
11
15456
1.56
1.61
0.09
2.52
0.35
0.43
6.56
12
16556
1.64
1.72
0.12
2.94
0.32
0.57
7.29
13
17656
1.87
1.80
0.09
3.36
0.34
0.37
7.82
14
19856
2.07
2.46
0.08
3.48
0.34
0.36
8.79
15
20956
2.28
2.04
0.08
3.60
0.35
0.49
8.84
16
22056
2.13
2.16
0.08
4.56
0.36
0.36
9.65
17
24256
2.04
2.21
0.07
4.09
0.32
0.38
9.11
18
25356
2.54
2.41
0.07
4.39
0.34
0.38
10.12
19
26456
3.02
2.92
0.08
4.68
0.35
0.37
11.41
20
28656
2.90
3.43
0.20
4.52
0.35
0.49
11.88
21-08-0206-01-0000
Result (graph view)
14.00
12.00
Series6
10.00
Series5
8.00
Series4
6.00
Series3
4.00
Series2
2.00
Series1
0.00
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21-08-0206-01-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 message processing time is the dominant cost and in this
implementation, the cost is largely due to Java thread hand-offs
• The sender ack processing cost is relatively high due to thread handoffs in
the implementation.
21-08-0206-01-0000