[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on the Draft
Tim, you are right. But, I really wasn't thinking about that way. I was thinking
of people knowing what internet sites I have been visiting and compiling some
kind of profile to sell to marketers, ..etc. Billing for specific content seems
to be only a small step away from that. Regards John
tim clifford wrote:
> john
> I think we could use a bit more granularity here. hopefully its clear that
> one wouldn't look inside the packet to see if its an email to grandma then
> charge accordingly. However, there's certainly a growing body of technology
> that looks at TCP port, ssl, cookie, http header, etc. to theoretically
> improve user experience. while there's questions about the scale and
> viability of these technologies they're certainly candidates for an
> operator's offering (or a third party for that matter.)
>
> john, check your web site for content delivery technologies ;-)
>
> tim
>
> Tim Clifford, President and CEO
> Lacuna Network Technologies, Inc.
> 5257 River Road #635
> Bethesda, MD 20816
> office: 703.812.8560 fax 703.812.8571
> mobile: 301.674.0373 email: tjc@lacunanet.net
>
> > -----Original Message-----
> > From: owner-more@ops.ietf.org [mailto:owner-more@ops.ietf.org]On Behalf
> > Of John G. Waclawsky
> > Sent: Wednesday, June 27, 2001 12:13 PM
> > To: kempf
> > Cc: takeshita@dcl.docomo-usa.com; more@ops.ietf.org;
> > Chris.Burke@motorola.com
> > Subject: Re: Questions on the Draft
> >
> >
> > In general, I believe snooping makes people nervous due security
> > and the potential
> > to collect information and misuse it somehow ...big brother and
> > all that.. etc.
> >
> > kempf wrote:
> >
> > > Chris,
> > >
> > > The question isn't charging per packet. That is already done, and is
> > > possible to do efficiently. CDPD does that (though, arguably, it is
> > > one possible reason why CDPD never took off, since customers don't
> > > like to pay that way, but that is a business issue...).
> > >
> > > The issue is charging based on the content of the packet. That requires
> > > L4 snooping if it is done in the network as opposed to on the end
> > > server. This could potentially slow traffic significantly.
> > >
> > > jak
> > >
> > > >From: Burke Chris-CCB007 <Chris.Burke@motorola.com>
> > > >To: "'Atsushi Takeshita'" <takeshita@dcl.docomo-usa.com>,
> > more@ops.ietf.org
> > > >Subject: RE: Questions on the Draft
> > > >Date: Wed, 27 Jun 2001 09:52:39 -0500
> > > >
> > > >There's something quite natural (from a technical or
> > operations perspective)
> > > about charging per-packet, since the charge is more-or-less
> > proportional to the
> > > amount of system resource used, and in this way, similar to
> > charging by the
> > > minute for voice services.
> > > >
> > > >Data-only services like the old ARDIS and Mobitex networks
> > charged by the
> > > packet. On ARDIS the charge was on the order of $0.25 per
> > kilobyte. 3G prices
> > > will not likely be this high, but let's take this price as a
> > boundary condition
> > > to investigate the impact of per-packet pricing on
> > applications. It leads
> > > quickly to radically different application economics than the
> > current internet.
> > > >
> > > >1) Applications and protocols running on per-packet pricing, should be
> > > optimized to minimize the total amount of data transmitted (to
> > minimize end-user
> > > costs). Contrast this with circuit-switched applications, which
> > should be
> > > optimized to send as much data as possible per minute of
> > connect time. Contrast
> > > also with generic internet applications, which typically assume
> > bandwidth is
> > > free (or at least follows Moore's Law) and optimize around
> > other factors such as
> > > ease of debugging (e.g. text-based protocols) or user experience.
> > > >
> > > >One of the best ways to minimize total data sent, is to make
> > the endpoints more
> > > intelligent. This drives thick clients (e.g. J2ME) rather than
> > thin clients
> > > (e.g. M-Services) to prominence.
> > > >
> > > >This also leads to increased demand from everybody, to make
> > "special" protocols
> > > for wireless applications, because - due not to technical
> > factors, but to
> > > carrier policy (i.e. decision to charge per packet) -
> > "standard" internet
> > > protocols are prohibitively costly to run.
> > > >
> > > >2) Many content application and service business models are
> > not viable unless
> > > the cost of transport is either negligible or deterministic.
> > (This is true in
> > > "real life" as well as over data networks). The RF channel is
> > non-deterministic
> > > (retransmissions, interrupted downloads, etc, will happen
> > regularly), and so
> > > strict per-packet billing will produce non-deterministic
> > overhead costs. This
> > > will be just fine for some business models (e.g. very high
> > content value / very
> > > high need for immediacy) but will slow the uptake of others.
> > > >
> > > >I understand the appeal of per-packet pricing. But to me, it
> > makes about as
> > > much sense as measuring software quality based on defects per
> > line of code -
> > > something done not because it makes sense, or because it
> > correlates to value,
> > > but because its easy and feels "quantitative".
> > > >
> > > >Chris Burke
> > > >Motorola Internet Software and Content Group
> > > >
> > > >-----Original Message-----
> > > >From: Atsushi Takeshita [mailto:takeshita@dcl.docomo-usa.com]
> > > >Sent: Tuesday, June 26, 2001 6:04 PM
> > > >To: more@ops.ietf.org
> > > >Subject: Re: Questions on the Draft
> > > >
> > > >
> > > >James,
> > > >
> > > >> 3) pg. 7 The Accounting section doesn't mention either of the two
> > > >> accounting protocols, Radius or Diameter. Since this document is
> > > >> meant to be foward looking, probably Diameter should be favored.
> > > >
> > > >I think Radius and Diameter are not requirements but examples of the
> > > >solution.
> > > >Does this I-D need to mention them?
> > > >
> > > >> 4) pg. 8 Do you want to be able to charge on packet content? This
> > > >> could result in *very* slow performance in some cases, if you
> > > >> need to snoop through to L4 to determine the port number.
> > > >
> > > >My personal opinion is that many or some operator will
> > > >prefer the idea of chaging on packet content
> > > >unless they find better charging method.
> > > >
> > > >------------------------------------------
> > > >TAKESHITA, Atsushi
> > > >DoCoMo Communications Laboratories USA, Inc.
> > > >takeshita@dcl.docomo-usa.com
> > > >Tel: 408-451-4705 / Fax: 408-573-1090
> > > >------------------------------------------
> > > >
> > > >
> > > >
> >