Subject: RE: [Sipping] Service Identification Model

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 1 Mar 2007 10:19:33 -0500

All,

Hypothetically, there could be a million services if carriers don't have
to settle for a Least Common Denominator solution, i.e. a standardized
list of services.

Cost to support on the network, and thus corresponding fees to the user
could be based on the nature of the QoS support required.

I would submit that the focus is misplaced on defining the set of
services.  Rather, the focus should be on defining the set of QoS that
has meaningful differentiation.

Further, I would suggest that the QoS class of services has two
dimensions:  Type and Volume.  For simplicity's sake, let us assume that
there are 2 types:  slow (above 150ms) and fast (under 150 ms), as well
as 2 sizes:  big (over 100 kbps) and small (under 100 kbps).  All the
permutations of those 2 dimensions would create four classes of service.

Of course, each dimension could be expanded to make this more granular,
but you get the idea.  Also, this undermines the cases where slow, small
services are charged disproportionately to the load on the network, just
because the user-perceived value has cleverly been marketed (e.g. SMS).
Perhaps, a third dimension would be storage (Y/N) to account for store
and forward facilities involved.  Other meaningful dimensions may be
possible.

Anyway, the point of all this is a suggestion to change the focus from
providing identity to the millions of possible services and focus on
identities for the classes of services into which the millions fall, and
which is much more likely to be standardizeable without inhibiting
innovation or interoperability.

Mike

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat) 
> Sent: Wednesday, February 28, 2007 1:37 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Service Identification Model
> 
> 
> 
> [email-masked] wrote:
> >    > 1. Basic Telephony (Conversational QoS Voice only with 
> telephony  
> >    > feature set)
> >    > 2. Multimedia Telephony (Conversational QoS Voice plus 
> video and other
> >    > media streams with telephony feature set)
> >    > 3. VoIP (Background QoS with no telephony features)
> > 
> > As Byron said, it's hard to see how 1 and 2 are different.  
> But 3 vs. 
> > 1 is an interesting matter -- the user can request 
> different grades of 
> > QoS and pay appropriately.
> 
> Sure, QoS can matter, and differ from call to call. But 
> calling each QoS option a different service is folly. QoS can 
> be *negotiated* rather than just declared. And when you can 
> have multiple media streams in the call, with differing QoS 
> needs, it would be insane to assign a different service name 
> to each combination.
> 
> 	Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 1 Mar 2007 07:36:13 -0800

Mike,

> Hypothetically, there could be a million services
Correct

How do you deal with an innovation that does not fall into a
standardized class? Outlaw it or start the standards work all over
again?

How does it fit with the e2e principle of with competitors not wanting
to share business oriented service definitions?

This is not meant as a jab, but I believe the wrong fundamentals when
trying to standardize anything related to services and service classes. 

Not to mention that QoS is considered by some as a DOS attack on the
competition :-)

> fees to the user could be based on the nature of the QoS support
>required.

Correct. It is called charging for broadband speed.

Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 9:20 AM
To: Paul Kyzivat (pkyzivat); [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Service Identification Model

All,

Mike

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 1 Mar 2007 11:05:26 -0500

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Thursday, March 01, 2007 10:36 AM
> To: Michael Hammer (mhammer); Paul Kyzivat (pkyzivat); 
> [email-masked]
> Cc: [email-masked]
> standardized class? Outlaw it or start the standards work all 
> over again?

You mean a service that is not  0 < S < infinity in size?
and not 0 < T < infinity in time delivery?  :)

> How does it fit with the e2e principle of with competitors 
> not wanting to share business oriented service definitions?

Because you don't ask the business what the nature of their game is, you
only ask them how big a field is needed for them to play their game.

> This is not meant as a jab, but I believe the wrong 
> fundamentals when trying to standardize anything related to 
> services and service classes. 
> 
> Not to mention that QoS is considered by some as a DOS attack 
> on the competition :-)
> 

What the local access can provide and what is used over a monthly time
period are two very different things.  If user usage was average and not
bursty on the service level, or not flash-crowd-like on a grander scale,
then life would be much simpler; but that is not reality.
 
> Henry

It seemed that some wanted some indication in the signaling path to
indicate the nature of what was being requested in the media path.  I
was only suggesting that having a way of saying whether it is bigger or
smaller than a breadbox, might help it get in the right ball park
without insisting that soccer is the only game that can be played.

Mike

> Hypothetically, there could be a million services if carriers 
> don't have to settle for a Least Common Denominator solution, 
> i.e. a standardized list of services.
> 
> Cost to support on the network, and thus corresponding fees 
> to the user could be based on the nature of the QoS support required.
> 
> I would submit that the focus is misplaced on defining the 
> set of services.  Rather, the focus should be on defining the 
> set of QoS that has meaningful differentiation.
> 
> dimensions:  Type and Volume.  For simplicity's sake, let us 
> assume that there are 2 types:  slow (above 150ms) and fast 
> (under 150 ms), as well as 2 sizes:  big (over 100 kbps) and 
> small (under 100 kbps).  All the permutations of those 2 
> dimensions would create four classes of service.
> 
> Of course, each dimension could be expanded to make this more 
> granular, but you get the idea.  Also, this undermines the 
> cases where slow, small services are charged 
> disproportionately to the load on the network, just because 
> the user-perceived value has cleverly been marketed (e.g. SMS).
> Perhaps, a third dimension would be storage (Y/N) to account 
> for store and forward facilities involved.  Other meaningful 
> dimensions may be possible.
> 
> Anyway, the point of all this is a suggestion to change the 
> focus from providing identity to the millions of possible 
> services and focus on identities for the classes of services 
> into which the millions fall, and which is much more likely 
> to be standardizeable without inhibiting innovation or 
> interoperability.
> 
> Mike
> 
> 
> calling each 
> > QoS option a different service is folly. QoS can be *negotiated* 
> > rather than just declared. And when you can have multiple media 
> > streams in the call, with differing QoS needs, it would be 
> insane to 
> > assign a different service name to each combination.
> > 
> > 	Paul
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 01 Mar 2007 10:21:45 -0600

Hi, Mike,

I may have misunderstood, but I thought Henry was saying that service 
definitions that did NOT fall into your model would be the problem. "When 
someone sends an INVITE tagged as service=grommet, what do you do, if you 
have no idea what a grommet is?"

Henry may also think there's a simpler model, of course :-)

Thanks,

Spencer

----- Original Message ----- 
From: "Michael Hammer (mhammer)" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>; "Paul Kyzivat (pkyzivat)" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 01, 2007 10:05 AM
Subject: RE: [Sipping] Service Identification Model

Mike

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 1 Mar 2007 12:34:41 -0500

I was arguing against need to define service=grommet in favor of 
service="smaller than breadbox", i.e. standard size box can be used to
ship it.

I was looking for a simpler model.

Henning wants nothing to be defined at all.

Mike

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Thursday, March 01, 2007 11:22 AM
> To: [email-masked]
> I may have misunderstood, but I thought Henry was saying that 
> service definitions that did NOT fall into your model would 
> be the problem. "When someone sends an INVITE tagged as 
> service=grommet, what do you do, if you have no idea what a 
> grommet is?"
> 
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 2 Mar 2007 14:18:59 -0800

> Use [email-masked] for new developments of core SIP

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 2 Mar 2007 14:18:59 -0800

Spencer,

> Henry may also think there's a simpler model, of course :-)

To see if there is a simpler model, it may be useful to look at Jonathan
Rosenberg's excellent list of SIP Extensions (only the standard track is
listed, the countless I-Ds in the pipe are not there):

http://www.jdrosen.net/rfcseries.html 

I wish you speedy approval of the budget to implement them all :-)

Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 10:22 AM
To: [email-masked]
Subject: Re: [Sipping] Service Identification Model

Hi, Mike,

I may have misunderstood, but I thought Henry was saying that service 
definitions that did NOT fall into your model would be the problem.
"When 
someone sends an INVITE tagged as service=grommet, what do you do, if
you 
have no idea what a grommet is?"

Thanks,

Spencer

----- Original Message ----- 
From: "Michael Hammer (mhammer)" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>; "Paul Kyzivat (pkyzivat)" 

Mike

> set of serviietf.org?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Spencer,

> Henry may also think there's a simpler model, of course :-)

To see if there is a simpler model, it may be useful to look at Jonathan
Rosenberg's excellent list of SIP Extensions (only the standard track is
listed, the countless I-Ds in the pipe are not there):

http://www.jdrosen.net/rfcseries.html 

I wish you speedy approval of the budget to implement them all :-)

Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 10:22 AM
To: [email-masked]
Subject: Re: [Sipping] Service Identification Model

Hi, Mike,

I may have misunderstood, but I thought Henry was saying that service 
definitions that did NOT fall into your model would be the problem.
"When 
someone sends an INVITE tagged as service=grommet, what do you do, if
you 
have no idea what a grommet is?"

Thanks,

Spencer

----- Original Message ----- 
From: "Michael Hammer (mhammer)" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>; "Paul Kyzivat (pkyzivat)" 

Mike

ces.  Rather, the focus should be on defining the