Re: [Sipping] RE: Queries and comments on draft-hilt-sipping-overload-00.txt

[Janet P Gunn <[e-mail]>]

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