(Caution you cannot configure from this post...) Mike Leber wrote:

As much as I like your idea :) I still have to poke holes in it.

Your *supposed* to.. that is creative collaboration. :)

On Sat, 22 Aug 1998, Richard Irving wrote:

...

Hoster's are rewarded for gaining popularity. (receiver)

They also get rewarded for have very large images, and 24 hour contious sound files, and live video, and contiously updating web pages.

*Live* video, and sound are usually push based. (See UDP/MULTI discussion) Otherwise, someone *clicked* to receive that stream.. Cacher's ? SYN fee, Ack fee, but reduced DS0mile/s... = Margin. (And cheaper surf) I am not sure what to do with the large images... Hrmmmm..... But, if the user didn't like the site, or it was slow.....and resulted in increased costs.. They wouldn't request the content as often. (Maybe ?) However, ** Imperative ! ** Hopefully any *single* ** web page a surfer hits would *almost* be inconsequential.. But, we are back to informing/involving the end user.... :( What to do with Continued Updates ?? Thoughts anyone... TCP based "Subscribers" should know.... (Option in browser to allow expires/refreshes/streams to work, after hitting site, like JAVASCRIPT, triggers a pop-up asking for permission ?) GOOD points, though !!!

Again, incentivizing bad behavior. Traffic for traffic's sake.

Probably would be better than incenting poor connectivity, at least we are motivating internet content, and connectivity. Without it, we would evolve to the PSTN. :( It sure would flesh out the "richness" of the surf "multimedia experience" :} And provide a method to compensate for that increased transmission volume... So, all of sudden "big" content doesn't cream pipe's, it pays for them. Local Browsers track DSO/s (Volume) from sites... Provides "Volume Util Analysis" with a click... And you learn to avoid those sites with the highest DS0/s/Per Page rating... Unless you really *like* that site... (It might, however, disourage the "surfing accelerators", why request a page you *may* not read....) Really, our problem isn't "big content", it is being able to get it there.... Today transmission is a balanced math equation , with *one* side of the equation "fixed" Our current model implies minimizing content transmission, because the sides *must* balance... Fix one side of the equation, and it will fix the other side... We keep trying to preach efficiency. (Content reduction) because pipe costs per volume today, are fixed... If those costs aren't so fixed.... Volume no longer becomes the concern, it becomes desirable, and supports itself, creating more pipe. The goal. Just thoughts... sure needs polish!