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: Frank A. Coluccio who wrote (4857)	7/29/1999 2:25:00 PM
From: Kenneth E. Phillipps	Read Replies (1) \| Respond to of 12823

Bell South brings CNN to wireless zdnet.com

To: Frank A. Coluccio who wrote (4857)	7/29/1999 11:24:00 PM
From: ftth	Read Replies (1) \| Respond to of 12823

Hi Frank, I don't recall the upstream post you mentioned (sorry, if I'm unable to follow the threads for several days or more, there are way too many posts to catch up on and I'm bound to miss a few). What do you mean by banner ad filtering? Rejecting/removing the original ad and inserting a new one? I don't understand what you mean by an "inverse effect" W/R/T the description of the CSCO product. As for where CSCO does their manipulation, anyone know if it is related to the "Access Control List Daughter Card" available with the Cayalyst 8500? Here's Cisco's info on the Catalyst 8500: cisco.com Access Control List Daughter Card New to the Catalyst 8500 Series, the access control list (ACL) daughter card provides an enhanced, policy-based management tool for converged network solutions. Leveraging Cisco IOS® to provide high-speed access control and security over Layer 3 traffic, the ACL card accommodates IP and IPX traffic and implements route filtering, source address port (SAP) filtering, media access control (MAC) layer filtering, as well as IP precedence QoS management

To: Frank A. Coluccio who wrote (4857)	8/10/1999 1:57:00 PM
From: Scott C. Lemon	Respond to of 12823

Hello Frank, I know that this is a late response, but I'm playing catch-up ... this thread is sometimes too busy with posts! (I love it, but get behind sometimes ...) > Dave, I find this quite alarming, but I shouldn't. Should I. > > "Without fully cutting off access to unaffiliated sites, the > technology allows a cable company to make such destinations appear > much more slowly on customers' computers than preferred sites, > Cisco claimed in brochures distributed at a recent appear much > more slowly on customers' computers than preferred sites, Cisco > claimed in brochures distributed at a recent..." This is the same kind of game played by search engines all the time. They have the ability to "bias" the search results in any way that they like. When Inktomi was at first demonstrating their search engine technology, this was one of the "features" that we touted ... the ability to "guide" the results of the search so that the user gets a response that is "favorable" towards one or more companies or industries. Understandably desirable feature ... yet scary for those who don't know it ... > You might recall my posting a hypothetical case upstream (about a > month and a half ago, somewhere here in LM), stating how I thought > it was conceivable to do context based screening and value-add > (selective QoS) at the ad banner level, by the providers of DSL > and other forms of dialup. In so doing, advertisers could cut deals > with the facilities based last mile providers, as opposed to the > ISPs, themselves. With the proxy/cache boxes that I have been working with it is becoming more and more feasible to even do this customization on a user-by-user basis. This would include things like QOS, banner ads, or even the language that the web page is displayed in. These features become very much like the ads that cable companies inject at the last mile ... except that now you really have it down to the user level of granularity ... > What the above quote from your message (italics) implies is > something similar, but with the inverse effect. Do you suppose that > this is url specific, or is it done by looking at the upper Layer > headers a al Layer 4/5 keyed? Any idea? In the proxies, the URL is hashed very effectivly at the application layer ... this is primarily for very fast cache look-ups ... but provides the same functionality to any process which wants to use it ... Scott C. Lemon