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
> >
>