North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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
   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
  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
  "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
  *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
  it becomes desirable, and supports itself, creating more pipe. 

  The goal.

  Just thoughts... sure needs polish!