RE: Questions on the Draft

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

sure but one of the issues one faces in this mobile - internet convergence
is terminology and definition.  the operators want to charge for "content,"
i.e., not be a bit pipe.  At face value, and imho, this is DOA.  however
there are likely to be more creative/insightful ways to meet this reqts.
statement than the obvious.

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: John G. Waclawsky [mailto:jgw@cisco.com]
> Sent: Wednesday, June 27, 2001 3:06 PM
> To: tim clifford
> Cc: kempf; Chris.Burke@motorola.com; more@ops.ietf.org;
> takeshita@dcl.docomo-usa.com
> Subject: Re: Questions on the Draft
>
>
> Tim, you are right. But, I really wasn't thinking about that way.
> I was thinking
> of people knowing what internet sites I have been visiting and
> compiling some
> kind of profile to sell to marketers, ..etc. Billing for specific
> content seems
> to be only a small step away from that.    Regards  John
>
> tim clifford wrote:
>
> > 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
> > > > >------------------------------------------
> > > > >
> > > > >
> > > > >
> > >