sale@ed.uucp (Ed Sale) (02/21/89)
I have just spent the large part of the day trying to determine if it is legal for an IP gateway to re-fragment an already fragmented datagram when it attempts to route the datagram from a network with a large MTU (Max Transmission Unit) to one with a smaller MTU. I have perused all *current* RFC's containing the word "fragment" and Douglas Comer's book to no avail. A simplified example of the problem arises when an 8 Kbyte UDP datagram originates on a network whose MTU is 2K bytes. The source must fragment the datagram before sending it and so makes 4 2K byte fragments. The destination of the datagram resides on another network whose MTU is 1 Kbyte. The fragments will be sent from the original source through 1 or more gateways to a gateway directly connected to the 1 Kbyte MTU network. This gateway will encounter fragments too large to send on the destination network. Is it legal for the gateway to make smaller fragments from the larger ones? The problem would also arise if any of the intermediate physical networks along the route had a smaller MTU than the original net. If the gateways can't re-fragment datagrams, the solution that immediately comes to mind is that when the datagram is originally fragmented that it be divided into some *small* fragment size that all gateways and physical nets supporting IP are required to handle. All IP implementations are required to have MTU's of at least 68 bytes one maximum sized (60 byte) IP header with one minimum-sized fragment (8 bytes). I sure hope that this isn't the case. Using this "make minimum-sized-fragments" scheme would reduce the throughput on large MTU nets, however, when sending large datagrams between two endpoints on the same network with an MTU smaller than the datagram size but much larger than the minimum size - unless a test was made before fragmenting to determine what the optimal fragment size should be. What do current implementations do? If there is an RFC addressing this please let me know so that I can read it. I apologize if this topic has been addressed in this newsgroup previously. Thanks for reading this far and (hopefully) responding. Ed Sale ..!uunet!ingr!b11!sale or b11!ed!sale@ingr.com
ken@ingr.com (Ken Cox) (02/21/89)
in article <4014@ingr.com>, sale@ed.uucp (Ed Sale) says: > > I have just spent the large part of the day trying to determine if it is > legal for an IP gateway to re-fragment an already fragmented datagram > when it attempts to route the datagram from a network with a large MTU > (Max Transmission Unit) to one with a smaller MTU. I have perused all > *current* RFC's containing the word "fragment" and Douglas Comer's book > to no avail. > RFC 791 addresses this problem, but you have to read carefully to find it. To summarize, you can fragment as long as the don't fragment bit is not set. The receiving end does not know or care how many times the original datagram has been fragmented. If you look at the fragmentation example in the RFC, it will clearly outline the algorithm for fragmentation (or re-fragmentation.) --Ken Cox
narten@PURDUE.EDU (Thomas Narten) (02/21/89)
It is perfectly legal and sometimes necessary to further fragment already fragmented datagrams. One item to watch out for is being sure that the MORE_FRAGMENTS bit is cleared only in the last fragment of the original datagram. That is, if a gateway fragments datagram A into AF1 and AF2, AF1 will have the MORE_FRAGMENTS bit set, while AF2 will have it cleared. If another gateway finds that it must fragment AF1, all of AF1's fragments (including the last one) would have the MORE_FRAGMENTS bit set. Similar considerations apply to the FRAGMENT_OFFSET field. 4.2 BSD got that case wrong the first time around, but it's been fixed for a long time. Thomas
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (02/21/89)
Fragmentation is addressed in RFC 791 section 2.4. All Internet hosts must be able to accept, at a minimum, a 576 octet packet. Re-fragmentation of an IP datagram is permitted as long as the "don't fragment" flag is not set.
postel@VENERA.ISI.EDU (02/22/89)
Ed Sale: It is "obviously" correct for a gateway to re-fragment a datagram fragment if it must be sent over a network with a still smaller MTU. --jon.
sale@ed.uucp (Ed Sale) (02/23/89)
Thank you all for responding to my query regarding re-fragmentaion of IP datagrams. It is legal. Ed Sale ..!uunet!ingr!b11!sale or b11!ed!sale@ingr.com
CERF@A.ISI.EDU (02/23/89)
Unless I have completely misunderstood the situation, it is always technically permissible to re-fragment an already fragmented IP DG. That is how fragmentation was designed to work. Vint Cerf
guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) (02/23/89)
Fragmentation is addressed in RFC 791 section 2.4. All Internet
hosts must be able to accept, at a minimum, a 576 octet packet.
Re-fragmentation of an IP datagram is permitted as long as the
"don't fragment" flag is not set.
I believe the specifications also require all networks to be able to
forward a 576 octet datagram without fragmentation. I can understand
logic behing this requirement as part of IP specifications. But I
wonder what would happen when the first ATM network joins the internet
with packet size of about 64 bytes. Most of the high speed packet
switches being desinged plan to conform to the ATM standards. In such
a mixed environment, does it make sense for an internet layer to
require a minimum packet size of all component networks. Is the packet
size an attribute to be specified by an internet layer or left to
the underlying networks to decide. What are the performance
implications of doing it one way or the other ?
(Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
in the existing environment, but I am looking beyond.)
I would like to see some discussion on this issue. Note that I am
talking about an internet layer in a generic sense and not challenging
IP specifications.
-guru
Dr. Guru Parulkar
Asst Professor guru@flora.wustl.edu
Dept of Computer Science parulkar@udel.edu
Washington University wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899
(314) 889-4621craig@SH.CS.NET (Craig Partridge) (02/23/89)
> I believe the specifications also require all networks to be able to > forward a 576 octet datagram without fragmentation. I can understand > logic behing this requirement as part of IP specifications. But I > wonder what would happen when the first ATM network joins the internet > with packet size of about 64 bytes. Most of the high speed packet > switches being desinged plan to conform to the ATM standards. In such > a mixed environment, does it make sense for an internet layer to > require a minimum packet size of all component networks. Is the packet > size an attribute to be specified by an internet layer or left to > the underlying networks to decide. What are the performance > implications of doing it one way or the other ? > (Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs > in the existing environment, but I am looking beyond.) Guru: My most recent reading of discussions of ATM (which if memory serves were in the latest issue of IEEE Network) suggested that the ATM folks had concluded that they needed some fragmentation/reassembly mechanism layered on ATM if they were going to support large datagrams. That's certainly consistent with the idea that ATM is simply a fancy way to multiplex a gigabit speed line. More generally, I think something is going to have to do this sort of fragmentation and re-assembly before data on an ATM network reaches an end-system (or maybe even an intermediate system). 64 octets implies a capacity to deliver as many as 2 ** 21 datagrams per second to the end system at one gigabit/second. That's about one datagram every 3 instructions right now (Using a 6 MIP SUN 4). If you naively follow the rule of thumb that processors double in speed every two years, that's still only 12 instructions in 1993! So even if the machine could interrupt that fast, you haven't a hope of processing the data coming in (parallel processors *might* help -- depends on how you design your system). So I suspect someone will have to fragment and aggregate somewhere in the ATM pipe. So yes, I think it is perfectly fair to choose a minimum datagram size (probably based on your minimum expectations of buffering in end-systems). In a gigabit realm, I'd suggest that size might well be several kilobytes. Craig PS: Some people may wonder why I picked the SUN as a candidate end-system. Many gigabit applications involve viewing graphics or data on graphics workstations -- I figure SUNs are *a* reasonable prototype of the type of machine (in cost/horsepower) that people will want to do these things on in the early 1990s. If you disagree with me, that's fine, choose your favorite machine architecture and berate me if your numbers are better.
narten@PURDUE.EDU (Thomas Narten) (02/23/89)
>I believe the specifications also require all networks to be able to >forward a 576 octet datagram without fragmentation. 576 is not a lower limit on the size of a datagram fragment, but an upper limit on what a destination is *required* to accept. The sender/destination might agree to exchange larger datagrams, but any such agreements are private to the communicating end points. From RFC-791: Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. Thomas
frg@jfcl.dec.com (Fred R. Goldstein) (02/24/89)
In article <8902230119.AA22877@flora.wustl.edu> guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) writes: > > Fragmentation is addressed in RFC 791 section 2.4. All Internet > hosts must be able to accept, at a minimum, a 576 octet packet. > Re-fragmentation of an IP datagram is permitted as long as the > "don't fragment" flag is not set. > >I believe the specifications also require all networks to be able to >forward a 576 octet datagram without fragmentation. I can understand >logic behing this requirement as part of IP specifications. But I >wonder what would happen when the first ATM network joins the internet >with packet size of about 64 bytes. Most of the high speed packet >switches being desinged plan to conform to the ATM standards. There is a simple answer to that question. ATM operates within the (OSIRM) Physical layer, while IP operates within the SNICP role of the Network layer. As nonadjacent layers, they do not have to get along. ATM cells (not "packets") carry fragments of data link layer packets ((or "frames", but not really frames in this case). A segmentation and reassembly function takes place atop ATM to allow large packets to be carried. One such technique is proposed in the current 802.6 letter ballot. ANother, called the ATM Adaptation Layer (AAL), has been bandied about the Broadband ISDN group. It is fatally flawed, as currently proposed, but it does support long packets. Any number of workable mechanisms (which would take the Data Link layer into account) can be created for this purpose. Or to look at it differently, T1 carrier with D4 channel banks uses 1-byte fragments, position-interleaved. ATM uses 64-byte fragments, labeled. But they're both down in mux-land, not in the subnetwork role that IP has to contend with. fred (T1S1 member)
braden@VENERA.ISI.EDU (02/24/89)
I believe the specifications also require all networks to be able to forward a 576 octet datagram without fragmentation. No, I don't think the specs say that. We certainly advise AGAINST networks with MTU's < 576 for performance reasons, but historically there have been several... Packet Radio Net and SATNET, if I remember correctly. If people implement the protocols correctly, communication should still function across a network with small MTU. Bob Braden
deering@PESCADERO.STANFORD.EDU (Steve Deering) (02/24/89)
> I believe the specifications also require all networks to be able to > forward a 576 octet datagram without fragmentation. That's incorrect, Guru. From page 25 of the IP spec (RFC 791): Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. Therefore, every network must be able to deliver 68 bytes of IP in one piece. This is still too long for the silly ATM stuff, but as Craig pointed out, transparent fragmentation and reassembly below the IP level is allowed by the IP architecture (and recommended for networks with ridiculously small MTUs). Steve