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

["Michael Hammer \(mhammer\)" <[e-mail]>]

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:[e-mail]] 
> 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" <[e-mail]> 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:[e-mail]]
> > 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 
> > [e-mail] for questions on current sip Use 
> > [e-mail] 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 [e-mail] for questions on current 
> sip Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP