Subject: RE: [Sipping] WGLC for draft-ietf-sipping-event-throttle-reqs-00.txt

From: "Eric Burger" <[email-masked]>
Date: Thu, 11 Mar 2004 09:03:29 -0500

Yes, you are.  LIOTO sounds like LOTTO, which is where you throw all of them out except for a random choice :-)

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, March 10, 2004 4:53 PM
> To: Eric Burger
> Cc: [email-masked]; Sipping (E-mail)
> Subject: Re: [Sipping] WGLC for
> draft-ietf-sipping-event-throttle-reqs-00.txt
> 
> 
> Eric,
> 
> I don't think you mean LIFO. That says that the last in is 
> the *first* 
> out, but implies that the ones in earlier will be delivered later.
> 
> I think you mean something like: LIOTO (Last In Out, Trash 
> Others). Am I 
> right?
> 
> 	Paul
> 
> Eric Burger wrote:
> > I'm actually saying just the opposite.
> > 
> > Consider the event package, "Where am I now?"
> > 
> > The ONLY sensible algorithm is LIFO.
> > 
> > 
> > Consider the event package, "Where have I been?"
> > 
> > A sensible algorithm is FIFO, as it would give the path of 
> my location.  Another sensible algorithm is FIFO with some 
> notifications dropped.  A reasonable algorithm is LIFO.
> > 
> > 
> > The PROBLEM is, a developer of the "Where am I now?" 
> package should not have to write a bunch of code that should 
> never get executed, namely, the FIFO, drop, or merge 
> algorithms.  They are just going to keep the last state 
> element and send it out when the throttle transmit conditions are met.
> > 
> > Allowing the client to specify the algorithm to use FOR ALL 
> EVENT PACKAGES (which is my objection in the first place to 
> the draft) just does not make sense.
> > 
> > 
> > 
> > -----Original Message-----
> > From: Alex Audu [mailto:[email-masked]]
> > Sent: Wednesday, March 10, 2004 3:48 PM
> > To: Eric Burger
> > Cc: Sipping (E-mail)
> > Subject: Re: [Sipping] WGLC for 
> draft-ietf-sipping-event-throttle-reqs-00.txt
> > 
> > 
> > Definitely, if you are doing something like presence-based 
> routing, you don't want to route
> > based on stale information.  And we don't have to implement 
> all possible buffer treatment 
> > methods. The current default looks like FIFO.  Adding LIFO 
> option wouldn't be too much work.
> > 
> > Cheers,
> > Alex.
> > 
> > Eric Burger wrote:
> > 
> > Is the subscriber in a position to dictate policy?  
> Probably not.  If so, we would mandate that every notifier 
> implement all possible methods (LIFO, FIFO, Drop, RED, 
> Concatenate, Merge, ...).
> > 
> >   
> > -----Original Message-----
> > From: Alex Audu [mailto:[email-masked]]
> > Sent: Wednesday, March 10, 2004 12:32 PM
> > To: Niemi Aki (Nokia-M/Espoo)
> > Cc: Eric Burger; Sipping (E-mail)
> > Subject: Re: [Sipping] WGLC for
> > draft-ietf-sipping-event-throttle-reqs-00.txt
> > 
> > 
> > Hello Aki,
> > 
> > My only concern with the draft is with section 4.3 (Post 
> > -conditions).  
> > Buffering may have
> > the effect of notifies carrying stale states, especially when the 
> > presence status is chaging rapidly.
> > It is also clear that notify policies like LIFO will help in 
> > this case. 
> > Can we add  a provision that
> > allows the subscriber to  specify the notify policy?  Options 
> > like LIFO 
> > and FIFO are the only
> > ones I could come up with.
> > 
> > Regards,
> > Alex.
> > 
> > Niemi Aki (Nokia-M/Espoo) wrote:
> > 
> >     
> > Hi Eric,
> > 
> > Thanks for the comments:
> > 
> > ext Eric Burger wrote:
> > 
> >       
> > On the technical content:
> > 
> > The document focuses on the rate of message generation.  
> >         
> > This makes 
> >     
> > sense if the resource to conserve is SIP stack processing 
> > (messages/second).
> >         
> > The resource to be conserved is also bandwidth - it is 
> >       
> > implicitly also
> >     
> > the target here.
> > 
> > All of this stuff also plays purely by statistics. It is not so
> > important to rate limit a specific source, but when throttles are
> > applied across many subscriptions, you lower the maximum 
> >       
> > aggregate rate
> >     
> > to expect.
> > 
> >       
> > As important as the rate is the bandwidth consumed by the messages 
> > (bytes/second).  Parameters here would be burst and sustained 
> > bandwidth used.
> >         
> > Yes, I agree that bandwidth is one aspect of reducing load. 
> >       
> > However, it
> >     
> > is much harder to articulate the behavior of the notifier 
> >       
> > in that case.
> >     
> > Rate (as in notifications per time unit) is already articulated in 
> > RFC3265.
> > 
> >       
> > On the work itself:
> > 
> > I still don't understand the purpose of this document.  It 
> > essentially says, "There are many ways of doing event throttling. 
> > Clients need to be able to ask for event throttling.  The 
> >         
> > server can 
> >     
> > throttle more than the client asks for."  Isn't that the normative 
> > behavior of RFC3265?
> >         
> > No, all of this is quite underspecified in RFC 3265. Also, these are
> > just the requirements for event throttles. A solution has 
> >       
> > been proposed
> >     
> > separately in draft-niemi-sipping-event-throttle-00.
> > 
> >       
> > Is this topic really the subject of an RFC?  What is the 
> >         
> > value to the
> >     
> >  community?
> >         
> > I don't really mind either way. One of the many 
> >       
> > justifications for I-Ds
> >     
> > to live is for discussion purposes, so not all I-Ds 
> >       
> > necessarily need 
> >     
> > to become RFC.
> > 
> > Cheers,
> > Aki
> > 
> > 
> >       
> > -----Original Message----- From: Rohan Mahy 
> >           
> > [mailto:[email-masked]] 
> >     
> > Sent: Monday, March 01, 2004 5:50 AM To: Sipping (E-mail) 
> >           
> > Cc: Rohan 
> >     
> > Mahy; Dean Willis; 'Gonzalo Camarillo' Subject: [Sipping] 
> >           
> > WGLC for 
> >     
> > draft-ietf-sipping-event-throttle-reqs-00.txt
> > 
> > 
> > Hi,
> > 
> > I'd like to begin WGLC for
> > 
> > 
> >           
> > http://www.ietf.org/internet-drafts/draft-ietf-sipping-event-t
> >     
> > hrottle-reqs-00.txt 
> >   
> > 
> > 
> > 
> >         
> > This WGLC will end on March 22, 2004.
> > 
> > 
> > _______________________________________________ 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
> >   
> > 
> > 
> > _______________________________________________
> > 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: "Eric Burger" <[email-masked]>
Date: Thu, 11 Mar 2004 09:07:34 -0500

More than the application.  The most important part is the event package itself.

Certain algorithms make sense for a particular package.  Others make no sense.  That is why total client control is a non-starter.

I could envision a negotiation protocol.  For example, in the location package I referred to before, the client could chose to make it a "where are you now" by requesting the LIOTO algorithm (yeah Paul!) or make it into to a "where you have been" by requesting the FIFO algorithm.  However, this implies that the event package is just a location package, and IT IMPLEMENTS BOTH ALGORITHMS.  The latter statement is the issue: it does not make sense to mandate that all packages implement all algorithms.  Once you say that, then you need negotiation.  One was to avoid negotiation is to define the methods on a per-event package basis.  That is EXACTLY the behavior we have today (e.g., no need for more documents to say, "do what we said you should do").

> Sent: Wednesday, March 10, 2004 6:19 PM
> To: Eric Burger
> Cc: Sipping (E-mail)
> I think the algorithm you chose depends on your application. If I am 
> interested in a
> trace of all the places my object of interest has been, then I think 
> FIFO is the way to
> go. 
> 
> Regards,
> Alex.
> 
> Eric Burger wrote:
> 
> >The PROBLEM is, a developer of the "Where am I now?" package 
> should not have to write a bunch of code that should never 
> get executed, namely, the FIFO, drop, or merge algorithms.  
> They are just going to keep the last state element and send 
> it out when the throttle transmit conditions are met.
> >
> >Is the subscriber in a position to dictate policy?  Probably 
> not.  If so, we would mandate that every notifier implement 
> all possible methods (LIFO, FIFO, Drop, RED, Concatenate, Merge, ...).
> >
> >  
> >_______________________________________________ Sipping mailing list

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 11 Mar 2004 09:11:29 -0500

Agreed.  In fact, this highlights why you cannot have arbitrary, client-imposed algorithm choices.  Unless negotiated or a base part of the package, the server will most likely offer only one or a small number of algorithms.  The choice of algorithm is, IMHO, simply a part of the filter specification.

Some packages will allow for history storage (e.g., potential for assured delivery) while others will not (e.g., potential for lost notifications).

Let us not also forget that for many packages, a composite state is entirely sensible (e.g., you have 1, 2, 3, 4 new voice messages = 4 new messages [could be seen as dropping 1, 2, 3; but also equivalent to "composite state = 4"]).

> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, March 10, 2004 9:35 PM
> To: Eric Burger; [email-masked]
> Cc: Sipping (E-mail)
> Subject: RE: [Sipping] WGLC for
> Eric:
> While I agree with your overall point, I have to take
> contention with one of your examples.
> 
> Eric Burger [mailto:[email-masked]] wrote:
> 
> > A sensible algorithm is FIFO, as it would give the path of my 
> > location.
> 
> As would single-element LIFO (or, as Paul put it, LIOTO). I think
> you've confused a "where have I been" event package with a (flawed)
> attempt to construct "where have I been" out of potentially
> lossy stream of "where am I" information gathered over a period of
> time.
> 
> A state representing "where have I been?" would necessarily include
> the path you're talking about.
> 
> As long as people have the misconception that they can throttle
> without losing information, people are going to continue to think
> that FIFO is somehow sensible.
> 
> /a
> 
>