Subject: RE: [Sipping] Update to event throttles

From: Eric Burger <[email-masked]>
Date: Tue, 26 Apr 2005 15:56:46 -0400

[Way late to the party - hope there is still some dip around :]

Again, doesn't this very thought (see bottom of thread) imply that filters
are, BY THEIR NATURE, event package specific? 

> -----Original Message-----
> On Behalf Of Paul Kyzivat
> Sent: Wednesday, March 16, 2005 11:32 AM
> Jonathan Rosenberg wrote:
> > Paul Kyzivat wrote:
> >> Aki Niemi wrote:
> >>> ext Paul Kyzivat wrote:
> >>>
> >>>> During the discussion at the meeting it struck me that 
> perhaps what 
> >>>> is needed is a bandwidth sensitive filter specification. 
> The basic 
> >>>> throttle mechanism doesn't necessarily reduce bandwidth, 
> while the 
> >>>> basic filter mechanism isn't time or size sensitive. A richer 
> >>>> filter mechanism could have more flexibility.
> >>>
> >>> Wouldn't using a throttle along with a filter achieve 
> exactly what 
> >>> you're after?
> >>
> >> Ho, I don't think that would be sufficient. The trick is that the 
> >> filter has to be able to make decisions about what to let through 
> >> that vary based on the resulting impact to required bandwidth. E.g.
> >> indicating that you would like geoloc info but are willing 
> to give it 
> >> up to achieve a desired bandwidth.
> >>
> >> I don't have a clear idea how one would express this. But I can 
> >> imagine applying one filter, then checking if the result fits a 
> >> throttle rate/bandwidth restriction, then if not applying a more 
> >> restrictive filter, etc.
> >>
> >> This puts the decision in the hands of the watcher about 
> what to give 
> >> up to achieve the desired objective.
> > 
> > Right. Its a hard problem, though. Let us say that the rate R of 
> > notifications generated is a function of the filter F. The 
> problem is 
> > to  adjust F over time such that R(F) is below some maximum 
> rate threshold.
> > Telling the server to do that amounts to providing a function that, 
> > for any unfiltered notification rate, generates a filter 
> that reduces 
> > the rate to the threshold. No idea how that could be done.
> 
> Agree that this may not be easy.
> 
> But that doesn't mean a way can't be found. The question is 
> whether the throttle mechanism otherwise solves the problem.
> 
> As an off-hand suggestion, how about just a sequence of 
> progressively more agressive filters? The server would apply 
> them one by one until the size of the message was 
> sufficiently small that sending it will conform to the 
> bandwidth constraint.
[snip]

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Apr 2005 16:52:39 -0400

> are, BY THEIR NATURE, event package specific? 

The subject of this thread was throttles. It was my proposal that 
filters are a way to achieve throttling.

I gave up on the entire thread. I just don't see any way to make 
throttling do anything helpful without all sources cooperating. And I 
see no way to achieve that.

	Paul