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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 3 Jan 2007 10:42:35 -0500

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
> 
> 
> "Darshan Bildikar" <[email-masked]> wrote on 
> 01/02/2007 11:35:04 PM:
> 
> > Hello Volker,
> >
> > Thank you for the response.
> >
> > My responses inline marked by <Darshan>
> >
> > BR
> > Darshan
> >
> > -----Original Message-----
> > From: Volker Hilt [mailto:[email-masked]]
> > Sent: Wednesday, January 03, 2007 9:39 AM
> > To: Darshan Bildikar
> > Cc: 'sipping'
> > Subject: Re: Queries and comments on 
> > draft-hilt-sipping-overload-00.txt
> >
> > Darshan Bildikar wrote:
> > > 1) How does this document relate to
> > > "draft-rosenberg-sipping-overload-reqs-01"? Does it take into
> cognisance
> > the
> > > requirements defined in this document?
> > >
> > Yes, it should.
> >
> > > 2) It is envisioned that overload information is 
> exchanged through a
> > header
> > > in response messages. Why not a more EXPLICIT mechanism like 
> > > SUBSCRIBE/NOTIFY? Define an event package for overload 
> and define a
> body
> > > that can be used to indicate a rich set of overload parameters to 
> > > the upstream entity.
> > >
> > Using SUBSCRIBE/NOTIFY would require a proxy to subscribe to a 
> > downstream neighbor when (or before) sending requests to 
> this neighbor 
> > to inquire the current load status. This would cause some messaging 
> > overhead, in particular, for proxies that talk to many downstream 
> > neighbors. The nice property of using a response header is 
> that it is 
> > very light-weight and it automatically provides feedback from the 
> > downstream entities a proxy is currently talking to.
> >
> > <Darshan 1> Say a downstream entity has indicated that it 
> is loaded at
> 100%.
> > This would result in the upstream proxy NOT forwarding it 
> ANY requests.
> How
> > does the proxy determine when to send the next request 
> then? It would
> never
> > know EXACTLY when the downstream element becomes available. 
> A sub/not 
> > mechanism allows the downstream element to indicate to an upstream
> element,
> > load status at discrete points of time instead of waiting for a 
> > request which might never come!
> >
> > Also, I don't agree that this would cause a messaging 
> overhead. It's 
> > just one more SIP dialog per downstream element. Even with your 
> > approach an upstream element still needs to maintain some kind of 
> > "STATE" about the
> load
> > of each downstream element. We only avoid the SIP messaging.
> >
> > What did you have in mind for the rich set of overload parameters?
> > <Darshan> By rich set, I only meant overload PER resource 
> instance on 
> > the SIP downstream entity.
> >
> > > 3) The draft talks about overload w.r.t certain resources. If a 
> > > sub/not mechanism was used, it would allow overload control to be 
> > > more "fine grained". For example, the SUBSCRIBE message would 
> > > indicate what
> resource
> > > the requester is wants the overload throttling and statistics for.
> > >
> > Overload control is used when a SIP entity is unable to handle all 
> > incoming messages because it ran out of resources it needs for 
> > processing messages. To an upstream neighbor, it really does not 
> > matter which resource on the downstream element is the bottleneck. 
> > What matters is that the downstream element can't process 
> all messages 
> > and, thus, the load has to be reduced. As long as the downstream 
> > element has enough capacity to return a meaningful response 
> (e.g. 488 
> > if a PSTN gateway runs out of trunk lines) it should do so.
> >
> > <Darshan 2> While I do agree with you, I think it's a 
> useful feature 
> > to
> be
> > able to throttle specific traffic. There is definitely a 
> use case for it.
> > Why should I waste time on generating 488 responses when I 
> KNOW that I
> wont
> > be able to process certain requests beyond a limit. If I am able to
> indicate
> > load to an upstream entity for a specific resource, I would 
> be able to
> run
> > my system much more efficiently. Ideally I SHOULD be able 
> to throttle 
> > my traffic in order to spend resources processing request I 
> KNOW I can
> handle
> > and not reject.
> >
> > It would also allow me to partition resources on my box 
> beautifully as 
> > I would be able to control requests I receive for a 
> particular resource.
> (I'm
> > thinking more from the point of view of an AS running services).
> >
> > > A use case that I can think of
> > >
> > > I have two applications on my box; CRBT and video conferencing. I 
> > > might
> be
> > > fast running out of ports for video conferencing but 
> might still be
> able
> > to
> > > do CRBT at 100%. I should be able to control the load based on the
> REQUEST
> > > URI.
> >
> > I don't think this is a valid example for the use of 
> overload control.
> > If the box is still able to do CRBT, it should also be able 
> to reject 
> > the additional requests for video conferencing.
> >
> > <Darshan> See previous response
> >
> > > I'm thinking that the SUBSCRIBE shall indicate, "Give me overload
> > statistics
> > > as if I were sending you this REQUEST URI". I'm assuming that a 
> > > request
> > URI
> > > maps to a "resource" but there could be a better way this could be
> done.
> > >
> > > This mechanism would help throttling based on SIP method, 
> URI, host,
> port
> > > etc and will be able to support REQ 18 defined in 
> > > draft-rosenberg-sipping-overload-reqs-01".
> > >
> > > Two things that I haven't really thought through.
> > >
> > > 1) Throttling based on codecs and media lines would be useful. For
> > example,
> > > I can support audio right now, but NOT video.
> > > 2) Is it possible to make this mechanism more generic? It 
> is after 
> > > all
> a
> > > throttling mechanism and could be applied to domains OTHER than
> overload
> > > control. For example, Tele voting applications where an 
> application
> server
> > > indicates filtering to a switch i.e. "Notify every 100'th 
> INVITE to me"
> > >
> > I don't think that the scope of overload control should be extended 
> > into these domains. Overload control specifically helps devices to 
> > deal with signaling overload. If a device is still able to return a 
> > SIP response it is not in signaling overload and should create a 
> > response with the appropriate response code.
> >
> > <Darshan 3> As I said I haven't really thought this through. My only
> point
> > being that we should try and "generify" wherever possible. 
> If someone 
> > decides to implement SIP mechanism for tele voting/throttling
> applications,
> > they would find that what they want to do is already ALMOST done in 
> > overload.
> >
> > Volker
> >
> >
> > _______________________________________________
> > 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: Janet P Gunn <[email-masked]>
Date: Wed, 3 Jan 2007 12:10:05 -0500

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 03 Jan 2007 14:03:17 -0500

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.

I'm neutral on this argument, but if it seems to make sense, it puts the 
topic outside the scope of SIPPING.

---

From: Volker Hilt <[email-masked]>
Date: Wed, 03 Jan 2007 16:08:36 -0500

> 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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 3 Jan 2007 15:42:11 -0800

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

Volker

>> and the others won't, leaving the overloaded box STILL overloaded,
but 
>> with