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

From: "Eric Burger" <[email-masked]>
Date: Wed, 10 Mar 2004 15:56:21 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Mar 2004 16:52:40 -0500

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

---

From: Alex Audu <[email-masked]>
Date: Wed, 10 Mar 2004 17:18:46 -0600

Hi Eric,

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.