Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading)

From: [email-masked]
Date: Thu, 14 Mar 2002 15:17:27 -0500

For a survey and references consult

http://www.comsoc.org/livepubs/surveys/public/2q00issue/pdf/DaSilva.pdf

"David R. Oran" <[email-masked]>@mailman.dynamicsoft.com on 03/14/2002
10:24:10 AM

Sent by:  [email-masked]

To:   "'Michael Hammer'" <[email-masked]>, "'Ben Campbell'"
      <[email-masked]>
cc:   "'Dean Willis'" <[email-masked]>, "'Dean Willis'"
      <[email-masked]>, "'Paul Kyzivat'" <[email-masked]>,
      <[email-masked]>

Subject:  RE: [Simple] Messages: Signaling, Data, or Theft (Was   something
      to do wit message threading)

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> Michael Hammer
> Sent: Wednesday, March 13, 2002 5:42 PM
> To: Ben Campbell
> Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat';
> [email-masked]
> Subject: RE: [Simple] Messages: Signaling, Data, or Theft
> (Was something to do wit message threading)
>
>
> Ben,
>
> When you consider RTP over IP, which fits your "IP
> application" definition,
> whether you charge per packet or realize that statistically X
> packets and Y
> minutes is "six of one, half a dozen of the other" then there
> are some
> models where per minute works out to be the same value.
>
Huh? What if I adaptively change my packetization perdiod based on
changes in loss patterns an end-to-end delay? If you do that you have to
count both bytes and packets and once you've done that minutes are
irrelevant (unless you want to gouge the user for silence periods). The
only time minutes might be relevant is if you want to charge for
*reserved resources*. If you do that, then you have the converse
situation - the only thing relevant to billing is the time the requested
resources are reserved, and bytes and packets don't matter.

The trap, as others have pointed out is to try to charge based on the
color of the bits, as opposed to what (if anything) the network does
with the bits.

> How do you reconcile volume charging with the two things that
> I noticed
> about my two services:  ISP:  Bills me a flat monthly fee for data
> service.  Mobile phone:  Bills me flat monthly fee for phone
> service, with
> per minute charges above an agreed on number of "free"
> minutes.  It didn't
> used to be like that.  Seems you are suggesting a
> trend-reversal or at
> least an exception to the rule.
>
> The earlier models of charging per data connection minute or
> per minute of
> call did not encourage usage and therefore generate enough
> revenue.  Per
> byte charges can generate revenue, but only if it doesn't
> discourage use.
>
> Will the per-byte prices be low enough to encourage use, yet
> still cover
> the cost of over-provisioning the network to keep setup delay
> low?  Will
> connection-less IM users pay a premium to make sure that
> connection-oriented RTP-flow users don't experience setup
> delays?  Tell me,
> who pays for excess capacity?  This could be a competitive
> discriminator.
>
All of this completely confounds *accounting* with *billing*. If you
don't account for anything other than the existence of a subscription,
then all you can do is flat-rate bill. If you count something, you can
certainly bill for it, but you don't HAVE to, and the discussion is no
longer technical but marketing, sales, and macro-economics.

As a side note, accounting (but not billing!) falls out of nearly any
QoS capability, since you need to count things in order to police and
shape traffic.

Dave.
> Mike
>
>
> At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> >You example only works when you apply a billing model (per minute
> >billing) to a medium (IP applications) where it doesn't make sense.
> >Indeed, I think the per-minute model is not so much expected by
> >users--it is just the carriers don't know how to bill any other way.
> >
> >If you applied a more IP Centric billing model (charge per
> byte), then
> >you can easily charge for signal and user data the same way. My GPRS
> >service provider charges for GPRS data in exactly this
> manner--if I run
> >a SIMPLE service across it, they just see bytes. A signal byte and a
> >user byte are indistinguishable.
> >
> >My personal nightmare is hearing that carriers want to charge X per
> >byte, except for bytes that were in SIP messages.
> >
> >
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]]On Behalf Of Michael
> >Hammer
> >Sent: Wednesday, March 13, 2002 9:41 AM
> >To: Dean Willis
> >Cc: 'Dean Willis'; 'Paul Kyzivat'; [email-masked]
> >Subject: RE: [Simple] Messages: Signaling, Data, or Theft
> (Was something to
> >do wit message threading)
> >
> >
> >Dean,
> >
> >There are some things users care about and will pay for, and other
> >things they won't.  For connection oriented services, they
> consider the
> >"air time" when they have full cut-through to when they get
> >disconnected to be the value.  In connectionless services, they care
> >about data packets getting through, not overhead signaling packets.
> >
> >You seem to be suggesting that the customer pay for the time
> they spend
> >waiting for the signaling to complete the call.  Or, you
> expect them to
> >pay for signaling as well as data-bearing messages.  This is
> analogous
> >to making customers pay for packaging, when all they want is the
> >handful of tablets in the little bottle inside the big box.
> >
> >Near where I live there is an ice-skating rink that charges by the
> >hour. Most people won't put up including in that hour the
> time taken to
> >fill out forms and select skates.  Nor would they pay for time where
> >they are standing in line for that process.  Not standing in line,
> >getting to the rink sooner, and skating a full hour have value.
> >
> >This is not just the service provider perspective, but the customer
> >perspective.
> >
> >It's OK to get philosophical, just keep it real. :)
> >
> >Mike
> >
> >
> >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> >
> >
> > > Warning: Philosophical Rant Follows
> > >
> > > The key issue is buried deep in the underlying business model. In
> > > the Internet world, you pay the same for the bits used to
> signal a
> > > multimedia session as for the bits used by the multimedia session
> > > itself. In the PSTN, the carriers pay for the signaling
> used to set
> > > up the multimedia session. In other words, there is NO
> signaling, as
> > > signaling is used in the PSTN sense, on the Internet -- just
> > > application traffic. There might be messaging
> applications, routing
> > > applications, management applications, or multimedia
> applications,
> > > but they're just all applications as far as the underlying
> > > network in concerned. In the PSTN, signaling actually
> > > traverses a separate, specialized network, driven by its own
> > > economic laws.
> > >
> >
> >Reference remaining rant elsewhere.
> >
> >Here's an example.
> >
> >-----------
> > From last year's Next Steps in Signaling BOF:
> >
> >6.5 James Kempf
> >    Radio access networks - air is expensive.  Optimize by using less
> >    bandwidth and more (for example) CPU cycles. Whatever
> the signaling
> >    protocol is, it must be very efficient for mobility.
> Providers pay
> >    big $$ for the airwaves, they don't want  to use it for
> signaling,
> >    but for user data.  Best: do the signaling through the
> backbone, and
> >    not over the air if possible.  The signaling must be
> efficient for
> >    mobility to minimize signaling while moving from area to area.
> >    Mobility signalling should be directly coupled to the traffic.
> >-------------
> >
> >See
> >http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> >
> >Clearly from the provider perspective, user data and
> signaling are two
> >different things. Therein lies the debate. For if a user were to do
> >something that "looks like" signaling, they would intrude on the
> >territory of the operator.
> >
> >The problem here: is Messaging the same as signaling? Is
> Presence the
> >same as signaling? Is anything we do with SIP really
> "signaling" or is
> >it user data?
> >
> >--
> >Dean
> >
> >_______________________________________________
> >simple mailing list
> >[email-masked]
> >http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >_______________________________________________ simple mailing list
> >[email-masked]
> >http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinf> o/simple
>

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple