[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on the Draft
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.
>From: Burke Chris-CCB007 <Chris.Burke@motorola.com>
>To: "'Atsushi Takeshita'" <email@example.com>, firstname.lastname@example.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".
>Motorola Internet Software and Content Group
>From: Atsushi Takeshita [mailto:email@example.com]
>Sent: Tuesday, June 26, 2001 6:04 PM
>Subject: Re: Questions on the Draft
>> 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
>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.
>DoCoMo Communications Laboratories USA, Inc.
>Tel: 408-451-4705 / Fax: 408-573-1090