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: E. Davies who wrote (4595)	7/13/1999 2:56:00 AM
From: Raymond Duray	Read Replies (1) \| Respond to of 12823

Hi Eric, split it into three virtual channels that use 50/20/10 Mbit. I'm sure that theoretically it could be done, If I understand you correctly, the multiple signals are to be sent on one frequency channel. An old fashioned TDMA scheme should suffice to provide the multiple signals. It seems to me this is just a restatement of the mux/demux problem. The 53 byte ATM-type muxing should be robust enough for streaming video or voice on multiple channels, as long as bandwidth is not constrained. Is there any other way to prevent one ISP from infringing on the performance of another except by assigning physical spectrum to each ISP? VPN protocols or PPTP or L2TP could possibly be called upon in a packet switched environment. CoS assignments, Password and firewall protection would provide the requisite control from one carrier stomping on a competitor. It's all theoretically possible as you say, but I doubt that subscribers are going to want to pay the cost of scaling down backbone solutions to the individual subscriber. $500 per month with good customer acceptance might just cover the development of such schema. This of course is just a WAG. But it is not a trivial problem and I'm sure the MSOs are loath to try such a convoluted plan.

To: E. Davies who wrote (4595)	7/13/1999 6:22:00 AM
From: elmatador	Read Replies (2) \| Respond to of 12823

DTM, perhaps? DTM is a network protocol for high speed networking developed for dynamic transport of integrated traffic. It is a transport network architecture based on circuit-switching augmented with dynamic reallocation of bandwidth. The protocol is designed to be used in integrated services networks and have support for point-to-point, multicast and broadcast communication, i.e., DTM network will be used for both distribution and unicast communication. www.netinsight.se DTM includes switching and a signalling protocol and can thus, in contrast to e.g., SDH/SONET, set up multi-rate channels (circuits) on demand, and the capacity of a channel can be changed according to traffic characteristics during operation. Additionally, resources can be reallocated between nodes according to the current demands. In this way, free bandwidth is allocated to nodes with highest demands, providing an autonomous and very efficient dynamic infrastructure.For a more detailed description, see our How DTM Works tutorial. A DTM network can be used directly for application-to-application communication or can be used as a carrier network for higher layer protocols, such as ATM or IP. DTM has the same type of framing structure as existing transport networks, SDH/SONET, using 125 us frames that are divided into time slot. However, DTM operates at layer one to three and thus, in contrast to for example SDH/SONET, includes switching and a signalling protocol. It is thus an alternative to using an ATM over SDH/SONET infrastructure. Due to the similarity to SDH/SONET frames, it can interoperate with existing SDH/SONET infrastructures, so DTM networks can carry SDH/SONET streams and SDH/SONET networks can carry DTM streams. Since DTM does not have the rigid hierarchical capacity levels of SDH/SONET, a much higher utilisation can be obtained when transporting data traffic, especially when adding the ability to dynamically adjust the capacity of the circuits according to the traffic characteristics. Still, DTM maintains many of the advantages of circuit-switched networks; guaranteed capacity, flow isolation and simple and deterministic QoS differentiation. The isochronous service provided by DTM also ensures a good support of both exisiting PDH/SDH structures as well as the increasing data traffic. Net Insight has developed an IP switch solution using DTM's switching capabilities. The IP switch solution handles data, voice and video smoothly and solves many of the problems associated with IP traffic in today's networks, e.g., provides bandwidth on demand, allows for preferential resource reservation, and supports multicasting

To: E. Davies who wrote (4595)	7/13/1999 7:00:00 AM
From: Frank A. Coluccio	Respond to of 12823

Eric, are you referring to the link that Dave Horne posted re: CDMA wireless or are you referring to cable modem, or what? exactly? I'll assume that you mean on cable's HFC systems. "...trying to learn whether there is technology that will allow splitting of physical bandwidth into multiple virtual channels for use in a multiple ISP cable environment." Virtual channels are feasible at the data link layer [Layer 2] such as I believe CMTO would allow, supporting permanent virtual circuits (pvc's) in ATM, for example, or through TDM fabrics which allocate channel sizing, or even by assigning other resource arbitration schemes such like routers do at Layer 3 through different port weightings. The answer to your question, in other words is, yes, it's doable and is being done, but the manner in which it takes place is in some way dependent on the supporting technology of the link. Regards, Frank Coluccio

To: E. Davies who wrote (4595)	7/13/1999 8:14:00 AM
From: Peter Ecclesine	Respond to of 12823

Hi Eric, Tolly Group, via Current Analysis, has four articles on this topic, and I am clipping from the summary: Bandwidth Starvation Results Report Data Report ID: 190707-0028-01.NV Analyst: E. Hold Issue Overview: Although only a relatively small number of products have been tested, it is clear that session starvation is emerging as a critical issue associated with delivering QoS capabilities. The fact that HP and at least one major vendor within our current sample fail to prevent session starvation points to the importance of the issue. Based on preliminary testing results as well as research into product specifications of other switches, it would appear that session starvation is an issue with some 30% to 60% of the LAN switch vendors. Furthermore, the current testing provides only a very basic look at QoS traffic management. Given the failure of devices to address such a basic concern, it is likely that significant implementation differences will emerge as more sophisticated QoS evaluations are done. CurrentPerspective: The ability to set a low priority bandwidth threshold is of key importance to the successful implementation of a policy networking solution. As such, we must take a negative position on any vendor that allows unmanaged bandwidth starvation of less important traffic. We feel that it is highly unlikely, in most circumstances at least, that users will be satisfied with any policy networking solution that causes this problem. After all, one of the key justifications for implementing a policy networking solution in the first place is the need to make more efficient use of the existing bandwidth. It is important to note that there are some justifications for bandwidth starvation, although this should still be the user's decision, not the switch vendor's. If the policy networking solution is implemented as a strategic component of a back-up solution (such as an ISDN connection), then the ability to starve certain traffic types becomes more important. However, the key point here is that bandwidth starvation must be the user's decision, not the vendor's; a "controlled starvation" solution. As a result neither the 3Com solution (which does not allow starvation) nor the HP solution (which does starve bandwidth) are truly ideal solutions. But, while both solutions are less than perfect, it is certainly preferable to ensure that that traffic is not starved in the switch. The results of the bandwidth starvation tests show that there are three broad categories of solution for the queue implementation scheme: No Cap: Bandwidth starvation is expected in times of congestion (for example, HP's ProCurve 4000M). Cap: Bandwidth starvation is avoided by setting a "cap" on the amount of bandwidth used by the high priority traffic. This is typically a 75/25% split (25% left for low priority traffic). A good example of this is the 3Com SuperStack switch Variable Cap: Bandwidth starvation is avoided by setting a "cap" on the amount of bandwidth used by the high priority traffic. This Cap is user-definable to allow for improved networks performance. Extreme Networks implements this solution with the Summit24. The nirvana for vendors is the variable cap solution, which provides the option of bandwidth starvation for backup situations, but in more usual circumstances ensures that the lower priority traffic is not starved out. Users should, however, look closely at the default implementation of this solution. Many vendors within this variable cap category set a default of 0% allocation to the low priority traffic - effectively providing a default of No Cap. Vendors need to address this issue, providing a default of 75/25.

To: E. Davies who wrote (4595)	7/15/1999 12:48:00 PM
From: Darren DeNunzio	Read Replies (1) \| Respond to of 12823

Regarding virtual channels... Eric, Your question is a valid one. Can one ISP prevent another ISP from infringing on their performance when both share the same cable. For residential Internet delivered over the cable plant, the norm is broadband LAN technology. This technology allows transmission of digital data over one or more 6 MHz channels of a CATV cable. The broadband LAN is built on top of two 6 MHz channels, one transmitting data from the headend to subscribers downstream, and the other transmitting data from subscribers to the headend upstream. At the headend, a frequency translator connects the two channels into a channel pair, so that data can be sent from one customer to another. The problem with the "virtual channel" is that currently, the upstream channels share the same spectrum between all of the subscribers. A weak attempt to illustrate my point is shown below. While there may be 15 downstream channels, they will all use the same upstream spectrum. MHz 0 20 40 60 80 +------------------+------------------+------------------+------------------+ \| upstream \| \| ch 2-4 \| spectrum MHz 540 560 580 600 ----------------+----------------+------------------+------------------+ \| ch 69-... \| \| \| \| \| \| \| \| \| \| \| \| 6 MHz downstream channels use same upstream spectrum Downstream transmission from the head end is "broadcast", as the same signal is sent on all the wires. Upstream transmission is inherently "personalcast", where each subscriber is trying to place a different signal onto the network. When going upstream, these different signals must eventually share the same piece of transmission spectrum. However to accommodate another ISP, or virtual channel, a separate upstream and downstream channel would be required. In any case, downstream channels will need to be given up by the MSO in order to accommodate other ISP's. Highly unlikely, IMO.