Re: Questions on the Draft

["John G. Waclawsky" <jgw@cisco.com>]

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