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 : LAST MILE TECHNOLOGIES - Let's Discuss Them Here -- Ignore unavailable to you. Want to Upgrade?

To: ftth who wrote (2464)	12/6/1998 4:44:00 PM
From: Frank A. Coluccio	Read Replies (3) \| Respond to of 12823

Dave, a truly well done synopsis on the security framework I inquired about. I appreciate it, and have book-marked it. I think that it says something [not sure just what, however] that the absence of these features and capabilities were never questioned in the older model of ILEC delivery in the past -- at least not to the same extent that they will now become an issue over shared-cable and shared-dsl environments. In the case of most cable company platforms, sharing takes place in the last several thousand feet, with potential for same at the head end if a collision domain hub is used. In the dsl model, it sometimes takes place at the host terminal either in the CO or at a pedestal, depending on architecture and the choice of dsl aggregation unit, but not on the wire pair into the home. In the home or business, however, where sharing is taking place, it is going to be a potential problem. The ATM type DSLAMs, however, don't fit this mold. >>This is too long already. Nobody reads these ultra-long posts.<< On the contrary. If you have more that you'd like to say on this topic, I'd surely like to hear it at the very least. Don't kid yourself, members here do tend to read long posts when they contain the kind of relevant information you've provided here. --- Maybe you could answer something for me here that's been on my mind for a while now. Where real-time or near-real-time services such as voice and video-conferencing are concerned, latency plays a big role in cost engineering and network economics problem-solving. I take it that there are measurable costs [delays] associated with authentication and authorization, and encryption, from a latency perspective: propagation times [to remotely situated servers]; encryption/decryption processing times; lookup times; acks-nacs; etc. How would you characterize these latencies? Are they significant enough to begin eating into the delay budgets where, say, VoIP is concerned? I ask this because security servers are not always proximate to the parties involved, during normal run of the mill VPN types of services, for example. But in those instances, an additional 100 to 200 milliseconds doesn't do any harm from a human perceptual perspective. In voice applications, on the other hand, they would push the acceptable delays [which are ordinarily thought to be on the order of 125 ms or so, nominally] over the top, so to speak. Actually, in the H.323 these already factor into the model, but I'm not quite sure how many full blown forum-sanctioned deployments of this there are out there, yet, and how they may have overcome what I'm referring to. Curious. ======================== >>Before I found this thread, I tried to start one myself called Broadband Communications Technologies, but it died a quick death.<< Subject 18943 I had not seen that thread before, elsewise, I'd have been on it for sure. I see Bernard Levy contributed there along with a couple of other familiar names. The other high capacity thread that sometimes add verbiage to is at: Subject 19393 ... titled: "Large Bandwidth Information, Companies , OC3, ADSL, WAVE." The Last Mile thread, however, seems to have subsumed both of them, even when techs discussed here tend to jut out into the WAN