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

From: "Eric Burger" <[email-masked]>
Date: Wed, 10 Mar 2004 13:29:41 -0500

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

---

From: Alex Audu <[email-masked]>
Date: Wed, 10 Mar 2004 14:48:27 -0600

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.