RE: Questions on the Draft

[Burke Chris-CCB007 <Chris.Burke@motorola.com>]

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
------------------------------------------