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

From: "Eric Burger" <[email-masked]>
Date: Fri, 5 Mar 2004 14:48:29 -0500

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).

As important as the rate is the bandwidth consumed by the messages (bytes/second).  Parameters here would be burst and sustained bandwidth used.

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?

Is this topic really the subject of an RFC?  What is the value to the community?

> -----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-throttle-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

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 10 Mar 2004 03:15:37 +0200

Hi Eric,

Thanks for the comments:

ext Eric Burger wrote:
> 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

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' 
> _______________________________________________ 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 11:31:32 -0600

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:

> 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