RE: Questions on the Draft

["tim clifford" <tjc@lacunanet.net>]

Chris
sorry i was pressed for time earlier today and only now got a chance to
spend some time with  your message.

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

is right on target. there's a training of intuition needed here to develop
more rational approaches.

tc

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 Burke Chris-CCB007
> Sent: Wednesday, June 27, 2001 10:53 AM
> To: 'Atsushi Takeshita'; more@ops.ietf.org
> Subject: RE: Questions on the Draft
>
>
> 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
> ------------------------------------------
>
>