RE: [802.21] FW: MIH fragmentation recommendation
Hi All,
No matter were we put the fragmentation function, don't get too hung up on how the MTU from the link or the UDP transport gets to the fragmentation 'entity.' That is possible in all implementations, from all MACs and all IP stacks. It's just OS impldep.
Regarding Stephen's comment, the use of MIH in state 1 via GAS should be examined, because GAS can do fragmentation according to Dave Stephenson.
We should also see a legitimate use case presented that makes the hard limit of 1500bytes not work. Otherwise, just declaring the MIH PDU MTU to be 1500 could also be viable.
BR,
Michael
-----Original Message-----
From: ext Dennis Edwards [mailto:dedwards@COCOCORP.COM]
Sent: 21 May, 2008 13:19
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] FW: MIH fragmentation recommendation
Yoshihiro, Stephen,
Thank you both for your comments. I see now that NET_SAP could be the wrong place to hide fragmentation. My motivation was (A) to inform the fragmentation service if it was needed over a particular network and (B) isolate the fragmentation service from the existing MIH state machines.
(1) I think that (B) can be satisfied with a façade between MIH and NET_SAP. I can see how the fragmenter would fit into Transmit() but not how putting the defragmenter into Process() would work in the existing state machines. If that is true...
(1.1) To satisfy (A), how would a façade determine, from the MIH_TP_Data.request arguments, if fragmentation is supported by the destination network? We can surely make inferences from something like LINK_TYPE but how is something like the LINK_TYPE value determined from the argument list?
(2) Maybe I don't understand how Link_PDU_Transmit_Status.indication works. Is not each MIH fragment likely to generate such an event? Also, in the case of reliable delivery by MIH over an L2 network, should the LINK_SAP wait for receipt of an acknowledgement by the source MIHF?
(3) I think that 5.7.2 of D10.0 should not say "L2 transport is not available" for other than 802.11 and 802.16.
(4) Is a "don't fragment" flag needed?
(5) Should we specify that a fragmentation time-out value needs to be established? A reassembly time-out value? If so, should these be added to the MIB or derived from the retransmission interval?
Dennis
-----Original Message-----
From: McCann, Stephen [mailto:stephen.mccann@roke.co.uk]
Sent: Wednesday, May 21, 2008 5:39 AM
To: Yoshihiro Ohba; Dennis Edwards
Cc: STDS-802-21@LISTSERV.IEEE.ORG
Subject: RE: [802.21] FW: MIH fragmentation recommendation
Dennis, Gabor,
I also agree with Yoshihiro, in that its better to define an MIH fragmentation service within the MIHF, as you have no knowledge of the specific media type beneath.
For example, there are use cases where 802.11 would utilise the MIHF without IP being established, and in this situation 802.11 can not provide SAR facilities over its air interface.
Kind regards
Stephen
> -----Original Message-----
> From: stds-802-21@LISTSERV.IEEE.ORG
> [mailto:stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Yoshihiro Ohba
> Sent: 21 May 2008 13:21
> To: Dennis Edwards
> Cc: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: 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
> >
>