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 : The *NEW* Frank Coluccio Technology Forum -- Ignore unavailable to you. Want to Upgrade?

To: axial who wrote (10912)	8/4/2005 3:09:16 PM
From: fred g	Read Replies (1) \| Respond to of 46821

> Not trying to be difficult, but if you're not inspecting content, then you have to be tracking usage. In what other ways could security be achieved? You do track usage. Whether you charge for it is a different matter, of course. The connection-oriented/connectionless wars of the early 1980s caused a lot of confusion. X.25 was designed for the remote TTY networks of the 1970s, over the awful analog wires common in Europe then. So it was slow and overly complex. The PTTs felt a proprietary kinship to it, though, and pushed for it to become the OSI CONS. Ugh. As a result, the world came to confuse "connection-oriented" with "X.25". But really, it only means that a relationship is created before data is passed, not that it has to be error-correcting and double-flow-controlled! Frame Relay SVCs are a lighter connection, though rarely implemented; likewise ATM SVCs. But those too are merely instances of things that are connections and are not X.25. What Cisco doesn't like to admit is that MPLS is also a connection-oriented (ooh, no, it a flow, not a connection!, say the IP fundamentalists, as they try to define themselves out of reality) protocol. Not that I'm calling for it. So basically you can have a lightweight connection option, wherein the network is aware that edge point X wants to send packets to edge point Y. (Firewalls and NATs have to do this anyway, by inference.) But that edge connection is still a sealed envelope. Nobody looks inside the packet. (Firewalls and NATs often break that already, though not maliciously.) And if you're going to allow the setup of lightweight (not error-correcting or flow-controlled) connections, you can allow different QoS options, different bandwidth options, and indeed different pricing options (low QoS for a flat rate, for instance, but premium streams for an additional fee). Heck, this could even help deter spamming, if the underlying connection setups were traceable. (BTW I think it would be wrong to charge for anything based on the application being used; rather, the application should request a service class from the network, without having to reveal what it really is.) How you implement this is the subject for interesting network research, which essentially needs to pick up where things got abandoned (most network research not directly tied to patching immediate TCP/IP problems) about 15-20 years ago. For instance, while it's intuitively obvious that you can implement QoS by using credits, reserved queues, and other such techniques at each switch/router along the way, there's some good evidence that the edges can usually find the QoS that the application requests, simply by careful timing and observation of packet flows. But that is not quite germane to this discusssion....