Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Voice-on-the-net (VON), VoIP, Internet (IP) Telephony -- Ignore unavailable to you. Want to Upgrade?

To: wonk who wrote (1766)	10/29/1998 4:30:00 PM
From: Frank A. Coluccio	Respond to of 3178

wonk, I'm not sure that the issues concerning trapping of header types and line protocols, and that severely related to total overhead. The the number of MIPS and DSP elements that are now available to do the necessary reads and crunching actually have minimized these effects. You just need to focus on the right attribute: Packet Size, a.k.a., cell size. The ATM cell size is inordinately small, resulting in a seemingly very high percentage of overhead. There are 5 overhead bytes and 48 payload bytes for a total cell size of 53 bytes. This results in an apparent overhead of approximately 11%. In reality, there is another unspecified percentage dedicated to overhead due to management frames outside the scope of normal payloads. This incremental overhead is dependent on other variables. The common benchmark used to assess OH is ~ 15% +/-. If we were to use the same overhead and apply it to a much larger packet (or cell) size, say of 1500 bytes, then you would see that the resultant overhead would only be on the order of 2% or 3%, total. The 53 byte cell size was a compromise which favored fluidity, i.e., how to get the most number of flows established with consistency through a node, without adversely impacting signal attributes, or the parameters affecting signal quality. Some factions in the standards bodies actually lobbied for much larger cell sizes than 53, but that's where it wound up. There's plenty of folk lore behind this and other standards, as to how they are arrived at at the ITU and the IETF, and to a lesser extent at the various technology-specific forums/fora. So once cannot always look to absolute logical reasons to prevail behind these decisions at times. [g] Regards, Frank Coluccio

To: wonk who wrote (1766)	10/29/1998 4:57:00 PM
From: Frank A. Coluccio	Read Replies (1) \| Respond to of 3178

wonk, what I meant to say in my opening paragraph was: >I'm not sure that the issues concerning the trapping of header types and the autosensing of line formats and protocols really have all that much to do today with any appreciable increases in total overhead. The number of processing MIPS and the DSP elements that are now available to do the necessary reads and crunching, have actually minimized these effects.< We've gotta get the fifteen minutes for editing extended to a half hour <s>