Subject: RE: [Sip] INFO considered harmful

From: "Eric Burger" <[email-masked]>
Date: Fri, 3 Jan 2003 13:06:55 -0500

The ironic part of the example:

SMS is given as one of the reasons that wireless is so cool and why wireless operators can make money.

SMS, in its present form, that is, not what "it could be", but what it IS, is given as an example of how to melt-down a signaling infrastructure.  SMS was supposed to be very infrequent, so it was thought to be OK to run it on the SS7 infrastructure.  No one anticipated the volume of point-to-point traffic SMS would generate.  One reason SMS took a long time to deploy in the US is because the Bellheads running the US wireless networks said, "SMS will overrun our poor STPs -- we can never deploy such a service."

Replace SMS with INFO, replace SS7 with SIP, and replace STP with SIP Proxy.

Not a value judgment, just an interesting look at how people that did the "wrong" thing made a boatload of money and managed not to melt the network (when there is a will and lots of money, a way gets found), and people doing the "right" thing are still trying to figure out if they should go Chapter 11...

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Friday, January 03, 2003 11:20 AM
> To: Jonathan Rosenberg; Henning Schulzrinne
> Cc: Adam Roach; 'Neil Deason'; [email-masked]
> Subject: RE: [Sip] INFO considered harmful
> 
> 
> And I will support that.
> 
> There may be a place for session based messaging, but for all 
> those uses where cellphone SMS constraints work today, 
> MESSAGE seems to be the appropriate solution.
> 
> By the way, when we do get session based messaging, it will 
> probably be impossible to write scoping rules that prevent 
> someone sending two MESSAGE requests to the same destination, 
> rather than setting up a session and sending two PDUs within 
> that session. All we will be able to do is provide guidance.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: [email-masked] 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: 03 January 2003 06:19
> > To: Henning Schulzrinne
> > Cc: Adam Roach; 'Neil Deason'; [email-masked]
> > Subject: Re: [Sip] INFO considered harmful
> > 
> > 
> > Henning is dead on.
> > 
> > I think we will always need MESSAGE for this reason exactly. 
> > It may be, 
> > that as messaging sessions are completed, and we understand 
> > the problem 
> > space better, we would revise MESSAGE to impose further 
> > restrictions on 
> > it. For now, I think its pretty good as written.
> > 
> > -Jonathan R.
> > 
> > Henning Schulzrinne wrote:
> > > Actually, there's an important difference: MESSAGE can 
> use the SIP 
> > > features outside an established session, while INFO is 
> > within a session 
> > > (and thus there are other SDP-negotiated, options 
> > available). Within a 
> > > session, the only real reason for a follow-the-INVITE SIP 
> > message is 
> > > that a direct IP-level connection can't be made to work.
> > > 
> > >  From an efficiency standpoint, if you only have very occasional 
> > > messages, you gain by a "connectionless" approach. After 
> > all, an INVITE 
> > > transaction for a single MESSAGE doesn't buy you much and doesn't 
> > > conserve the oh-so-precious proxy cycles. While such short 
> > sessions are 
> > > probably not common for human-to-human communication 
> > (except spam...), 
> > > they may well be common for the type of things that SMS and 
> > pagers are 
> > > popular for: machine-to-human or machine-to-machine 
> communications 
> > > announcing infrequent and unpredictable events ("your 
> flight is now 
> > > leaving on gate 37", "your FedEx just arrived", "Server 42 
> > is on fire").
> > > 
> > > Adam Roach wrote:
> > > 
> > >>> From: Neil Deason [mailto:[email-masked]]
> > >>>
> > >>> Actually if we want to police protocol usage closely we 
> > had better 
> > >>> look at deprecating MESSAGE too.
> > >>
> > >>
> > >>
> > >> Come back when SIMPLE has finished defining the message sessions,
> > >> and I'll throw my voice behind yours in advocating this.
> > >>
> > >> /a
> > >> _______________________________________________
> > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >> This list is for NEW development of the core SIP Protocol
> > >> Use [email-masked] for questions on current sip
> > >> Use [email-masked] for new developments on the 
> application of sip
> > > 
> > > 
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use [email-masked] for questions on current sip
> > > Use [email-masked] for new developments on the 
> application of sip
> > > 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> > 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Jan 2003 14:22:42 -0500

To add additional perspective: In 2001, 200 billion SMS were sent (for 
GSM, 
http://www.idg.net/idgns/2001/05/29/UPDATE2StudySMSMessagesWillTop200.shtml). 
Comes to about 6400/second. Assuming that a reasonably well tuned server 
can handle 100/messages a second, that requires about 100 servers, 
multiplied by the number of network hops (residential and small-business 
end hops don't matter since they are not likely to be congested). Total 
cost some small multiple of $100k. This total would be sufficient to 
handle the service for all GSM carriers, worldwide. I don't think that's 
a major factor in any protocol debate.

In general, I just don't buy server load arguments. If it's a useful 
service, server cost is usually the least of the problem. In any event, 
one should take this as a fraction of the existing signaling load, not 
as some absolute number. I'm worried about stuff that multiplies the 
signaling load by a factor of 10; I find 20 or 50% load increase 
uninteresting as an argument. (Thus, while I find 'INFO-for-DTMF' 
distasteful, the signaling load is the least of the problems, given that 
most phone calls will see at most a handful of touch tone digits.)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jan 2003 17:34:15 -0500

inline.

Henning Schulzrinne wrote:

> uninteresting as an argument.

My firsthand experience with selling stuff to carriers is that this is 
most definitely not the way they see it. Remember, the equipment 
purchases are made up front before the service is activated. If you can 
sell a carrier a solution that requires 50% or even 20% fewer boxes, 
thats a big win. Its not just the equipment cost, its the management 
cost too that increases with the box counts.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Jan 2003 22:00:44 -0500

I'd imagine they do care when they talk to you since that's the cost 
element that they can control during that conversation. They probably 
also try to bargain hard with the copy paper people.

Why would anybody buy extra servers for demand that isn't going to 
materialize for (say) months? Stocking up on servers isn't exactly the 
best return on investment - it's not like OPEC is going to raise their 
prices next year. I suspect that the major cost is not the hardware but 
the per-server software licenses :-)

If you can get a service deployed today rather than waiting for a new 
protocol to be standardized and deployed, and if you're paying interest 
on your 3G license loan, I'd imagine that speed-to-working beats request 
counts.

Since this is all hypotheticals, we can probably agree that server cost 
is just one of many factors. Deployability, system management complexity 
(more protocols=more MIBs), staff training and maturity of the 
alternatives and time-to-market all matter, but are hard to quantify.

Jonathan Rosenberg wrote:
>> service, server cost is usually the least of the problem. In any 
>> event, one should take this as a fraction of the existing signaling 
>> load, not as some absolute number. I'm worried about stuff that 
>> multiplies the signaling load by a factor of 10; I find 20 or 50% load 
>> increase uninteresting as an argument.
> 
>

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 04 Jan 2003 14:08:29 -0600

The server hardware cost is probably the least to worry about, rather it
is as mentioned here:

>Deployability, system management, complexity 
> alternatives and time-to-market.

Signaling load is also not too much a problem, if not excessive. I would
rather worry about servers with geographic diversity and the most
effective DNS schema for fast response. 

My two cents, Henry

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Henning Schulzrinne
> Sent: Friday, January 03, 2003 9:01 PM
> To: Jonathan Rosenberg
> Cc: Eric Burger; [email-masked]
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>