RE: Questions on the Draft

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

I agree that L4 snooping is problematic, both for overhead reasons (although there are hardware snooping technologies that reduce this) and for end-to-end reasons (can't snoop encrypted packets). I think the two arguments go hand-in-hand: per-packet charging has fundamental flaws, some of which have to do with application economics, others of which have to do with technology.

The same set of issues apply to QoS - how does one set up appropriate QoS for an encrypted data stream, and charge for it? The two problems may have the same answer. If a way can be found to charge for what is essentially a virtual circuit with specific attributes, independent of the content and therefore without the need to snoop it, that same technique can be applied to any kind of streaming content.

This pushes the billing decisions to the edge of the network, where something about the application data stream is directly knowable, rather than into the core of the network, where anything knowable about the data stream must be deduced from examination of raw packets (which might be impossible anyway under IPSEC et al).

Chris

-----Original Message-----
From: kempf [mailto:James.Kempf@Sun.COM]
Sent: Wednesday, June 27, 2001 7:35 AM
To: takeshita@dcl.docomo-usa.com; more@ops.ietf.org; Chris.Burke
Subject: RE: Questions on the Draft


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