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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 3 Jan 2007 13:53:36 -0500

Janet,

I know it would be simpler to ignore anything not SIP, but in fact SIP
is designed to set up all sorts of sessions defined in SDP that SIP is
blissfully unaware of, since the nature of the media is an SDP issue not
a SIP issue.

Similarly, the Event framework enables reporting of "events" in the SIP
Notifies without any constraints (as far as I can tell) of what can be
defined as an event.  The structure of an event is whatever event can be
defined in XML.

This is a case where thinking could go outside the SIP box, if one were
so inclinded.

Mike

> -----Original Message-----
> From: Janet P Gunn [mailto:[email-masked]] 
> Sent: Wednesday, January 03, 2007 12:10 PM
> To: Michael Hammer (mhammer)
> Cc: Darshan Bildikar; sipping; Volker Hilt
> Subject: RE: [Sipping] RE: Queries and commentson 
> draft-hilt-sipping-overload-00.txt
> 
> 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