Reviewer's name:Title: Hardware/Software Organization of a High-Performance ATM Host InterfaceAuthor: C. Brendan S. Traw and Jonathan M. SmithRatingsEvaluation of work and contributionOriginality, NoveltyRelevance to the call for papersReadability and organizationOverall recommendationSummaryCommentsFuture WorkCS 740Reviewer's name: Title: Hardware/Software Organization of a High-Performance ATM Host InterfaceAuthor: C. Brendan S. Traw and Jonathan M. SmithRatingsEvaluation of work and contribution35=Excellent work and a major contribution4=Good solid work of some importance3=Solid work but marginal contribution2=Marginal work and very minor contribution1=Very questionable work and contributionOriginality, Novelty25=Trailblazing4=A pioneering piece of work3=One step ahead of the pack2=YAPA(yet another paper about...)1=It's been said many times beforeRelevance to the call for papers25=Right on target4=Definitely relevant3=Close enough2=Not really appropriate for SIGCOMM '931=Definitely inappropriate for SIGCOMM '93Readability and organization25=Very good4=Basically well written3=Readable2=Needs considerable workPage 1CS 7401=Unacceptably badOverall recommendation25=Definitely accept (very high quality)4=Accept (good quality)3=Accept if room (marginal quality)2=Likely reject (low quality)1=Definitely reject (has no merit)Page 2CS 740SummaryThis paper describes an implementation of a SONET-based ATM host adapter for an IBM RISC System/6000 host with Microchannel bus. The authors briefly describe some other implementations, then discusses the hardware architecture. The host adapter is implemented as a two-board set consisting of a segmenter and reassembler. The authors also describe the host software support under AIX, with some performance measurements. Finally, they conclude with a discussion of performance bottlenecks and future work.CommentsThe overall organization of this paper is no better than average. Grammatically the paper was fine. I didn’t find any typographical errors. The diagrams and code examples range from trivial (i.e., Figure 8) to meaningless (vc_t structure definition).A particularly poor feature of the paper is the treatment of acronyms. There is considerable “alphabet soup” in the paper, especially in section II on “Related Work.” Mostly, the explanations behind the acronyms go unstated as well. In addition the test results are not very comprehensive, and only sketchy details of the testing are given.The main problem is that the authors describe the hardware and software in a cursory manner, but do not really give the “big picture”. Instead, they discuss certain details of the design without giving the rationale for some of the large-scale tradeoffs that were made. Of course, the authors aren’t going to describe the system in enough detail to reproduce it, sincepresumably it will become a commercial product.The single largest unanswered questions in the paper is: what are the design goals of the host interface? The authors simply say they want “high performance”, “low cost”, and “flexibility.” Such descriptions are completely inadequate. These criteria need to be defined much more carefully for a hardware project rather than software, because of the expense in time and materials to correct them if they were incorrect or unworkable. Also, there is other way to determine if the design is successful. For example, a worthwhile performance criterion should measure transfer rates in bytes per second for certain specified packet sizes, host loads, and other factors that need to be explicitly stated. The authors claim that the design achieved “90% of the performance of the hardware subsystem.” Is this acceptable, or not?Cost is arguably the most important constraint in the design. It doesn’t matter how great something is if no one can afford it or buy it. Presumably, this system will go into production, but no target cost is stated. Perhaps this is so readers will not know the profit margin on the host interface if it is ever offered for sale!Page 3CS 740Even so, there are a number of cost issues that could be discussed but were not. For example, how does the cost of this interface compare to others? Where are the cost tradeoffs of getting custom parts made? What is the expected quantity for production? How can the device be tested in a cost effective manner?On an hardware/architectural level, the implementation is not very innovative. The design only implements low levels of ATM, but this is by the designers’ choice. The hardware uses dual port memory, hardware linked-list maintenance, copy avoidance, and other techniques which are common design practice in devices of this nature. There is nothing really new or enlightening about the design.Most of the design is implemented with field-reprogrammable gate array technology. Interestingly, the authors eschew an implementation with another CPU. They claim this allows for “low cost” and that such an implementation would be a “difficult solution.” Both of these claims are debatable. First, an implementation with an external CPU is not necessarily more expensive. Granted, CPUs require memory and other “glue” hardware, butthe are very high volume products, and their price declines rapidly over their product life. Also, newer family members usually become available which cost less and can run the same firmware even faster. The programmable logic used in the design will not exhibit the same price erosion. Second, one can argue the relative difficulty of programming a processor in some language to accomplish a task compared to writing logic equations for dedicated hardware. But certainly, the processor approach is more flexible. And performance will not automatically suffer. In fact, the authors mention another source who implemented an ATM host adapter with two CPUs that gets “the highest burst performance reported for an ATM host interface”, presumably including their own!The authors implement the host adapter on the IBM Microchannel bus used on the RS/6000 workstation. While Microchannel is not technically proprietary, almost no one uses it but IBM. The authors could have used the alternative “memory” bus on the RS/6000, but decided against it so they could communicate with other bus cards as well (a worthwhile idea).However, the authors discovered that the Microchannel I/O controller (which must pass all data between the host adapter