Re: [802.21] FW: MIH fragmentation recommendation
Hi Dennis,
I mostly agree with your analysis.
An MIH fragmentation service would be better defined in MIHF not in
NET_SAP. This is because NET_SAP in its current design is not
supposed to know the format and semantic of MIH PDU including MIH
header.
Regards,
Yoshihiro Ohba
On Tue, May 20, 2008 at 09:17:16PM -0700, Dennis Edwards wrote:
> Gabor,
> There were many things said in the meeting. It still seemed worth recording, if only in summary, how we could get away with not employing PMTUD, not changing existing state machines, not requiring exhaustive simulation and so on. Such things still seem to be concerns within the group. Your observation of where fragmentation should occur is appreciated. As I said later, an MIH fragmentation service need only be employed in a NET_SAP where it makes sense to do so, like atop 802.3, for which general support seems a foregone conclusion. You are also, of course, right about IPv6, I did not mean to imply otherwise. Thank you for your clarification.
> Dennis
>
> From: Gabor Bajko [mailto:Gabor.Bajko@NOKIA.COM]
> Sent: Tuesday, May 20, 2008 5:42 PM
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: Re: [802.21] FW: MIH fragmentation recommendation
>
> This is a good summary, however, I do not think it contains any additional information to what we already discussed in the meeting.
>
> Regarding the following paragraph:
>
> If the method in section 6.5.3 of D10.0 can be can be used to limit the query response size of all MIH messages then the maximum size of any indivisible MIH protocol element would be 1492 bytes. If such a limit is enforced by the specification then fragmentation is not needed to support the MIH protocol. If such a limit cannot be enforced then fragmentation and reassembly are required and the fragmentation threshold is established at 1500 bytes.
>
> I agree with the second sentence, but the third sentence needs some clarifications: I think the author meant that when MIH message size can exceed 1500 bytes, then support for fragmentation is needed either at MIH or any layer below MIH layer.
>
> Both IPv4 and IPv6 support (transparent) fragmentation. The only difference of fragmentation in IPv6 compared to the one in IPv4 is that when fragmention is necessary, that has to be done at the source, routers can not fragment an IPv6 packet. That being said, I think that the statement we heard in the meeting, i.e. that when IP is used to transport MIH, MIH does not need fragmention and the MIH messages do not need to be limited, still holds.
>
> The problem is only when 802.3 is used without IP on top of it. Because sending data between two endpoints without using IP addressing is not realistic any more, the problem is limited to the cases when MIH is part of control or management plane of that medium. Since I do not know about any effort in this direction, I am wondering whether the problem does really exist, even if only in theory.
>
> - Gabor
>
> ________________________________
> From: ext Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM]
> Sent: Tuesday, May 20, 2008 1:59 PM
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: [802.21] FW: MIH fragmentation recommendation
> fyi
>
> ________________________________
> From: Dennis Edwards [mailto:dedwards@cococorp.com]
> Sent: Tuesday, May 20, 2008 10:14 AM
> To: Gupta, Vivek G
> Subject: MIH fragmentation recommendation
>
>
> Any fragmentation mechanism depends on a packet fragmentation threshold. If the packet size is not greater than the fragmentation threshold then the packet is not fragmented, otherwise it is. The fragmentation threshold can be set to the Path Maximum Transport Unit (PMTU) by a dynamic discovery mechanism (e.g.: RFC 1191<http://tools.ietf.org/html/rfc1191>, RFC 1981<http://www.tools.ietf.org/html/rfc1981>, RFC 4821<http://tools.ietf.org/html/rfc4821>); can be arbitrarily established as part of a protocol definition (e.g., IEEE 802.11-2007); or it can be set through some management interface (e.g., IEEE 802.11-2007). The options are not mutually exclusive.
>
> Some protocols, such as IPv6, require all links to support a minimum MTU. Limiting the maximum MIH message to 1492 bytes (1500 bytes - 8 bytes for the MIH protocol header) will make it compatible with transparent bridging (c.f., RFC 3580<http://www2.tools.ietf.org/html/rfc3580#section-3.10> [section D.3.10, IEEE 802.1X-2004]). The MIH protocol could, similarly to IPv6, require that all links provide for a minimum 1500 byte payload and admit lack of support for links such as those described in RFC 3150<http://tools.ietf.org/html/rfc3150>.
>
> For the remainder of this discussion I assume that the steps in the preceding paragraph have been taken and both the minimum and maximum MIH payload are thus each fixed at 1500 bytes: This would eliminate the need for any MTU negotiation or configuration to determine the maximum response size limit of a participant in an MIH transaction.
>
> h
>
> The rest of my comment assumes that fragmentation is, indeed, required.
>
> In version four of the TCP/IP protocol suite, TCP packets may be transparently fragmented by IP. This is known to be variously problematic (c.f., Christopher A. Kent, Jeffrey C. Mogul, Fragmentation Considered Harmful<http://citeseer.ist.psu.edu/335647.html>). If such problems are acceptable in light of the expected application of the MIH protocol then no changes are needed to the MIH protocol state machines in order to support fragmentation and reassembly of MIH protocol messages. The fragmentation mechanism can be selectively established as part of any NET_SAP for which the underlying media does not already provide a fragmentation service. MsgInAvail would only be signaled, via MIH_TP_Data.indication, following successful reassembly of a fragmented packet. When Transmit() signals an MIH_TP_Data.request then the MIH payload would be transparently fragmented and encapsulated appropriately according to the underlying media requirements.
>
> The leftmost reserved bit in the MIH header could be used to signal the presence of an MIH fragmentation option, similarly to IPv6. Only a NET_SAP would ever see this header option. There are many ways the fragmentation option field could be defined. One possibility is to make the option field 4 bytes wide and to define the following sub-fields:
>
> * Most significant two bytes could be the fragment offset into the original message
> * The next most significant byte could be a fragment number
> * The least significant byte could be a flags field, one bit of which is set to indicate more fragments remain.
>
> By defining the MIH fragmentation service in this way, we are allowed significant freedom in its specification. We could, for instance, utilize an existing fragmentation mechanism that has already been well specified, established and tested and so provides a minimal risk to the MIH standard approval and subsequent implementations. One such option is the IPv4 fragmentation service. We could rely on the procedure defined in section 2.3 of the IPv4 protocol specification (RFC 791<tools.ietf.org/html/rfc791>) for outgoing message fragmentation while relying on RFC 815<http://tools.ietf.org/html/rfc815>, IP Datagrams Reassembly Algorithms, for fragmented message reassembly. An Analysis of Fragmentation Attacks<http://www.ouah.org/fragma.html> could serve as a reminder of some implementation details to consider.
>
> Dennis Edwards
> Platforms Architect
> CoCo Communications
> 999 3rd Avenue
> Suite 3700
> Seattle, Washington 98104
> (206) 812-5723
>