wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) (03/25/89)
Well, OSI seems to be the wave of the future :-), so we might as well get used to it. I'm working on several projects that will be using OSI-based protocols, and I'm concerned about what the performance of the system will be like. OSI has a reputation for dogginess, but is it really justified, or is it just that most implementations have been new enough mot to be highly tuned yet? One of the applications we're looking at will be using the misnamed OSI IP internet protocol (ISO 8473) over X.25. We know how the current DoD IP based system performs - will an ISO-based system be about the same speed, or slower, or faster? Thanks; Bill Stewart -- # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # Washington, DC. Raining. Long, cold, heavy rain. Been raining for days. # I was here last year in the spring. It was raining like this then, too.
joel@arizona.edu (Joel M. Snyder) (03/25/89)
8473 should perform at about the same speed as IP. I implemented ISO IP by editing DoD IP code and doing a bit of twiddling of the field positions. 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. Other than that, the protocols are almost identical. Of course, some of this depends on whether or not you've been computing your IP checksum (and your TCP checksum :-) :-) ). Joel Snyder U Arizona MIS Dep't ANSI X3S3.7
karn@ka9q.bellcore.com (Phil Karn) (03/26/89)
>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
mogul@decwrl.dec.com (Jeffrey Mogul) (03/29/89)
In article <14957@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >>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. > [...] >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. As Chris Kent and I wrote (after Dave Mills raised the issue) in our paper "Fragmentation Considered Harmful" (SIGCOMM '87), one problem is that because IP doesn't tell you how much space is needed, you can run into pseudo-deadlock when several large packets are being reassembled. If the rate of incoming fragmented packets is high enough, it doesn't matter how much memory you have, because the situation is unstable: once you begin to run out of memory, you're likely to see new fragments arrive faster than the old ones time out. The real problem, of course, is that IP-style internetwork fragmentation is generally a bad idea ("Harmful", in fact). Issues of "efficiency in the use of memory" are second-order compared to efficient mechanisms for avoiding fragmentation. I certainly agree with Phil that variable- length fields are a false economy. -Jeff