Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SH.CS.NET!craig
From: craig@SH.CS.NET (Craig Partridge)
Newsgroups: comp.protocols.tcp-ip
Subject: re: Re-fragmenting IP Datagrams
Message-ID: <8902232053.AA29014@ucbvax.Berkeley.EDU>
Date: 23 Feb 89 13:27:52 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 49


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