Xref: utzoo comp.protocols.iso:259 comp.protocols.tcp-ip:6600 comp.protocols.misc:533
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!ka9q.bellcore.com!karn
From: karn@ka9q.bellcore.com (Phil Karn)
Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject: Re: TCP/IP vs. OSI Performance
Message-ID: <14957@bellcore.bellcore.com>
Date: 25 Mar 89 21:39:04 GMT
References: <529@skep2.ATT.COM> <9882@megaron.arizona.edu>
Sender: news@bellcore.bellcore.com
Reply-To: karn@ka9q.bellcore.com (Phil Karn)
Organization: Secular Humanists for No-Code
Lines: 37

>It turns out that ISO IP is more efficient in its use of
>memory; you know at the first fragment the length of the entire message,
>so you can preallocate...

I don't quite understand this. If you represent packets as linked lists of
dynamically allocated buffers, then there is no need with either DoD IP or
ISO 8473 to preallocate memory when reassembling fragments. You just keep
the pieces in a sorted linked list, with "fragment descriptors" telling you
where the holes are. As each fragment comes in, you trim off any overlap and
insert (link) it into the proper place.  When all the holes are filled in
and the last fragment (MF=0) has been received, you're done. I suspect
preallocating space means you intend to do memory-to-memory copying. It may
be easier to code, but it's best avoided for performance reasons.

It is true that knowing how long an entire datagram is could save you some
CPU time if you're so memory-starved that you won't be able to reassemble
it; you could toss all of the fragments as soon as you receive them instead
of running out of memory halfway through reassembly and having to toss the
partially reassembled datagram.  I don't see this as a big advantage,
though, since any system that runs out of memory often enough for this to be
a signficant performance factor is going to have many other, much more
serious problems.

One important factor re ISO 8473 performance that hasn't been mentioned yet
is its fetish for variable length fields. These are inherently harder to
deal with than DoD IP's nice fixed-length fields (IP options are rare enough
in most environments that they can be largely ignored as a performance
issue).  It's a *lot* easier to deal with 32-bit IP addresses on machines
that support native 32-bit integers than it will be to handle the monster
variable length byte strings that make up ISO addresses. Van Jacobsen once
commented to me that much of his header prediction work is likely to be
inapplicable to ISO.

Yet another excellent reason to question whether the whole ISO "trip" is
necessary -- as if the many reasons already stated aren't enough...

Phil