RE: Questions on the Draft

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

john
I think we could use a bit more granularity here.  hopefully its clear that
one wouldn't look inside the packet to see if its an email to grandma then
charge accordingly.  However, there's certainly a growing body of technology
that looks at TCP port, ssl, cookie, http header, etc. to theoretically
improve user experience.  while there's questions about the scale and
viability of these technologies they're certainly candidates for an
operator's offering (or a third party for that matter.)

john, check your web site for content delivery technologies  ;-)

tim

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 John G. Waclawsky
> Sent: Wednesday, June 27, 2001 12:13 PM
> To: kempf
> Cc: takeshita@dcl.docomo-usa.com; more@ops.ietf.org;
> Chris.Burke@motorola.com
> Subject: Re: Questions on the Draft
>
>
> 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
> > >------------------------------------------
> > >
> > >
> > >
>