Subject: RE: [Sipping] RE: Queries and commentsondraft-hilt-sipping-overload-00.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 5 Jan 2007 17:47:20 -0500

Henry,

No flames, the difference is a matter of context or assumptions about
the envisioned architecture that might result in overload or not.  You
were thinking in terms of the original P2P vision of SIP.  I was
thinking in terms of the IMS variety where the question of how many
INVITEs/second does it take to bring down a SIP proxy, especially if UDP
is used and re-transmissions start to compound the problem till no
useful work gets done, or worse it crashes.

You have a logical conclusion about the approach to avoid the problem to
begin with, given some of the architectural design choices you make,
based on certain factors that have no value for you.

Did you mean incremental complexity over what has already been
introduced? :)

Mike

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Thursday, January 04, 2007 10:03 PM
> To: Michael Hammer (mhammer); Volker Hilt; Tom-PT Taylor
> Cc: sipping
> Subject: RE: [Sipping] RE: Queries and 
> commentsondraft-hilt-sipping-overload-00.txt
> 
> Mike,
> 
> > overload of end host node supporting VoIP application
> 
> Maybe we pull out our laptops (end host node) at the IETF 
> meeting and you can show me how a VoIP application can 
> overload it. Unless you have an antique PC with collectors' value :-)
> 
> The same applies to SIP phones. DDOS is a security issue.
> 
> > over-provisioning may not always be the most cost-effective use of 
> > resources.
> 
> A comparison between the cost of over-provisioning and the 
> cost of complexity would indeed be very interesting for VoIP 
> before plunging into the SIP overload work.
> 
> > Hope that restores your sanity. :)
> 
> Not quite.
> 
> Maybe we have a misunderstanding and you refer to the endless 
> collection of SIP feature servers in VoIP networks, in which 
> case I am in full agreement. The correct alternative to this 
> is to place the features in the end host nodes (SIP UA) and 
> use SIP as it is defined in RFC 3261: 
> A discovery and rendezvous protocol (with as little state in 
> the proxy as possible).
> 
> Let the flames come...
> 
> Henry
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 11:00 AM
> To: Henry Sinnreich; Volker Hilt; Tom-PT Taylor
> Cc: sipping
> Subject: RE: [Sipping] RE: Queries and
> commentsondraft-hilt-sipping-overload-00.txt
> 
> Henry,
> 
> This has nothing to do with router congestion and everything 
> to do with overload of end host node supporting VoIP 
> application, which is more akin to an unintentional DDOS.
> 
> And yes, one can always throw more hosts at the problem, but 
> over-provisioning may not always be the most cost-effective 
> use of resources.
> 
> Hope that restores your sanity. :)
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:[email-masked]]
> > Sent: Wednesday, January 03, 2007 6:42 PM
> > To: Volker Hilt; Tom-PT Taylor
> > Cc: sipping; Michael Hammer (mhammer)
> > Subject: RE: [Sipping] RE: Queries and 
> > commentsondraft-hilt-sipping-overload-00.txt
> > 
> > Volker is 100% correct and I would only like to add that a 
> little more 
> > bandwidth (think of all the multimedia and animated web commercials
> > flowing) and modern processors are far cheaper and more 
> effective in 
> > avoiding overload in the first place.
> > 
> > Sanity check: VoIP traffic is so small, that it is hard to 
> detect on 
> > the net :-)
> > 
> > Thanks, Henry
> > 
> > -----Original Message-----
> > From: Volker Hilt [mailto:[email-masked]]
> > Sent: Wednesday, January 03, 2007 3:09 PM
> > To: Tom-PT Taylor
> > Cc: sipping; Michael Hammer (mhammer)
> > Subject: Re: [Sipping] RE: Queries and 
> > commentsondraft-hilt-sipping-overload-00.txt
> > 
> > Tom-PT Taylor wrote:
> > > One of the proposals going around TISPAN was for a separate
> > overload
> > > control protocol, for exactly the reason you point out: 
> > that you may
> > > need to control for overload from multiple application 
> protocols on
> > the
> > > same box. Another argument, applying even to 
> single-protocol boxes,
> > was
> > > that this would be more effective than defining new overload 
> > > capabilities in a multiplicity of protocols.
> > > 
> > A downside is that all SIP boxes need to implement the 
> protocol stack 
> > of
> > 
> > the stand-alone protocol for this to work well. Also, the 
> stand-alone 
> > protocol stack would have to have hooks into all other protocols to 
> > actually facilitate the throttling (what if it doesn't?). E.g. it 
> > would have to have a way to instruct the SIP protocol stack on the 
> > upstream entity to reject a certain fraction/rate of 
> messages. During 
> > operation, the protocol would have to exchange some kind of 
> messages 
> > (maybe similar
> > 
> > to SUB/NOT) which again contribute to messaging traffic. A 
> mechanism 
> > directly built into SIP does not have these problems and 
> seems to be 
> > simpler and easier to deploy.
> > 
> > Volker
> > 
> > 
> > 
> > > Janet P Gunn wrote:
> > >> Mike,
> > >>
> > >> Good point..
> > >>
> > >> Obviously everything is simplest if we are only dealing with one 
> > >> protocol.
> > >>
> > >> If the box is serving multiple protocols, I would assume that 
> > >> detecting/identifying overload applies to the machine, not the
> > protocol
> > >> (e.g , cpu usage, internal queue length, time in  queue).
> > >>
> > >> SIP can, of course, only address signalling the overload to other
> > boxes
> > >> that "talk" SIP.  Obviously, if that "other box" is
> > sending both SIP
> > >> messages and other-protocol-messages to the overloaded
> > box, it would
> > be
> > >> nice/ sensible if the "other box" throttled all messages (SIP or
> > >> otherwise)
> > >> to the overloaded box.  But I don't think SIP can specify that.
> > >>
> > >> If the overloaded box talks to some boxes that "talk" 
> SIP, and some
> > that
> > >> don't, there is always the possibility that the SIP 
> boxes will cut
> > back,
> > >> and the others won't, leaving the overloaded box STILL 
> overloaded,
> > but
> > >> with
> > >> non-SIP work.  Obviously this wouldn't be a good idea.  I
> > don't think
> > we
> > >> can necessarily assume it away, but I don't think we can
> > "solve" it
> > >> with a SIP document.
> > >>
> > >> Janet
> > >>
> > >>
> > >>
> > >> "Michael Hammer \(mhammer\)" <[email-masked]> wrote on
> > 01/03/2007
> > >> 10:42:35 AM:
> > >>
> > >>> Janet and others,
> > >>>
> > >>> Just out of curiosity, do you assume that SIP is the ONLY
> > protocol
> > >>> operating on a particular platform?
> > >>>
> > >>> If not, then do you assume that each protocol has its 
> own oveload 
> > >>> control mechanism and that each will independently 
> determine when
> > the
> > >>> machine is overloaded?
> > >>>
> > >>> Mike
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Janet P Gunn [mailto:[email-masked]]
> > >>>> Sent: Wednesday, January 03, 2007 8:53 AM
> > >>>> To: Darshan Bildikar
> > >>>> Cc: 'Volker Hilt'; 'sipping'
> > >>>> Subject: Re: [Sipping] RE: Queries and commentson 
> > >>>> draft-hilt-sipping-overload-00.txt
> > >>>>
> > >>>>
> > >>>>
> > >>>> I think it is important to focus on overload of the ability to 
> > >>>> PROCESS SIP messages.  In particular, the focus should 
> be on the 
> > >>>> situation where, if the SIP messages keep coming, the box will 
> > >>>> crash (usually preceded by unproductive thrashing).
> > >>>>
> > >>>> As such, the mechanism and messaging must be as "lightweight"
> > >>>> as possible, in order to avoid making the machine
> > congestion worse.
> > >>>>
> > >>>> The other kinds of resource specific overload mechanisms you 
> > >>>> discuss sound very useful.  But I don't think it is a
> > good idea to
> > >>>> try to overload them on THIS effort.
> > >>>>
> > >>>> Janet
> > >>>>
> > >>>>
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > 
> 

_______________________________________________
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: Fri, 5 Jan 2007 15:27:40 -0800

Michael,

> I was thinking in terms of the IMS variety

I have no idea how IMS can be really scalable and robust, especially in
a multi-vendor environment.

Following the latest I-Ds about SIP routing in such networks, the best I
can say is "it is work in progress" after all these years.

There are also no operational reports on IMS networks that have even
remotely the size of Skype.

Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 4:47 PM
To: Henry Sinnreich; Volker Hilt; Tom-PT Taylor
Cc: sipping
Subject: RE: [Sipping] RE: Queries and

Henry,

Mike