North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
- From: Richard Irving
- Date: Sat Aug 22 14:38:55 1998
(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
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...
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 ?)
** 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
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
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
Unless you really *like* that site... (It might, however, disourage
"surfing accelerators", why request a page you *may* not read....)
Really, our problem isn't "big content", it is being able to get it
Today transmission is a balanced math equation , with *one* side of
the equation "fixed"
Our current model implies minimizing content transmission, because the
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
it becomes desirable, and supports itself, creating more pipe.
Just thoughts... sure needs polish!