Subject: RE: [Sip] PUBLISH message rates

From: "Chris Boulton" <[email-masked]>
Date: Thu, 13 Nov 2003 12:58:41 -0000

Ben,
<<see comments>>

	-----Original Message----- 
	From: Ben Campbell [mailto:[email-masked]] 
	Sent: Thu 13/11/2003 03:28 
	To: Adam Roach 
	Cc: [email-masked]' 
	Subject: Re: [Sip] PUBLISH message rates

	Are we assuming that any event package can automatically be used with
	publish? Or do we expect explicit documentation about how to use publish
	with a package? Maybe future event packages should document use of
	publish as part of the package documentation.

	<< I think that we have to assume that every event pacakage COULD use PUBLISH in some

	shape or form.  Even if initially the use does not seem obvious.>>
	
	If we do expect package specific documentation for the use of PUBLISH,
	then it wouuld make sense to ask for it to specify the behavior just
	like we expect package documentation to do it. One option would be to
	state that the rules are inherited from the NOTIFY documentation. But
	for some packages, other approaches may make sense.

	<<  I may be missing something BUT I don't see how this helps, especially in the case of 

	large (and potentially  expanding) numbers of PA all Publishing at the same time.>>   
	
	Adam Roach wrote:
	
	> To get the conversation started on the list, I'll summarize
	> what I heard as salient points being made at the microphone.
	>
	>  - Event packages define SHOULD or MUST strength requirements
	>    that NOTIFYs cannot be sent faster than a hard limit.
	>    Aki's proposal can be summarized as: PUBLISH will inherit
	>    these hard limits as maximum rates of publication.
	>
	>  - It was pointed out that recipients of PUBLISH requests can
	>    push back against excessive traffic with 5xx class responses
	>    that have "Retry-After" headers.
	>
	>  - A point was made that NOTIFY will often be subject to filtering,
	>    in which case there is no one-to-one correlation between the
	>    amount of information sent to an event server in PUBLISH and
	>    the amount of information sent by an event server in NOTIFYs.
	>
	> To be honest, after giving the topic a bit more thought, I'm
	> somewhat on the fence.
	>
	> /a
	>
	> _______________________________________________
	> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
	> This list is for NEW development of the core SIP Protocol
	> Use [email-masked] for questions on current sip
	> Use [email-masked] for new developments on the application of sip

	_______________________________________________
	Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
	This list is for NEW development of the core SIP Protocol
	Use [email-masked] for questions on current sip
	Use [email-masked] for new developments on the application of sip

J*fj)b�	b��m��?�0�'�~���f��f��X��)ߣ�"�8b�X��+��DYׯzZ)�����ay�+y">�-��%RǬ����W�z{h��,r�n���y۟���z�b�{(�˫����*T��"����'�~��~��{^��h�g���'����bq�b�z�*

---

From: Aki Niemi <[email-masked]>
Date: Thu, 13 Nov 2003 23:51:54 +0200

ext Chris Boulton wrote:
> Ben, <<see comments>>
> 
> -----Original Message----- From: Ben Campbell
> [mailto:[email-masked]] Sent: Thu 13/11/2003 03:28 To:
> Adam Roach Cc: [email-masked]' Subject: Re: [Sip] PUBLISH message
> rates  
> 
>  publish? Or do we expect explicit documentation about how to use
> publish with a package? Maybe future event packages should document
> use of publish as part of the package documentation.
> 

> If we do expect package specific documentation for the use of
> PUBLISH, then it wouuld make sense to ask for it to specify the
> behavior just like we expect package documentation to do it. One
> option would be to state that the rules are inherited from the NOTIFY
> documentation. But for some packages, other approaches may make
> sense.
> 

It doesn't. That is a separate problem, and one way to address this 
would be the SIP level push-back from the composer.

I'm inclined to agree with Henning on this. We could inherit the event 
package specific limits, but in PUBLISH, they are even more useless. At 
least in NOTIFYs, given the default rate of 1/x, the subscriber can 
calculate the absolute aggregate rate of its y subscriptions: y * 1/x.

The composer doesn't have that possibility.

Cheers,
Aki

Adam Roach wrote:  > To get the conversation
> started on the list, I'll summarize > what I heard as salient points
> being made at the microphone. > >  - Event packages define SHOULD or
> MUST strength requirements >    that NOTIFYs cannot be sent faster
> than a hard limit. >    Aki's proposal can be summarized as: PUBLISH
> will inherit >    these hard limits as maximum rates of publication. 
> > >  - It was pointed out that recipients of PUBLISH requests can >
> push back against excessive traffic with 5xx class responses >
> that have "Retry-After" headers. > >  - A point was made that NOTIFY
> will often be subject to filtering, >    in which case there is no
> one-to-one correlation between the >    amount of information sent to
> an event server in PUBLISH and >    the amount of information sent by
> an event server in NOTIFYs. > > To be honest, after giving the topic
> a bit more thought, I'm > somewhat on the fence. > > /a > >
> _______________________________________________ > Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW
> development of the core SIP Protocol > Use
> [email-masked] for questions on current sip > Use
> [email-masked] for new developments on the application of sip    
> _______________________________________________ Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip 
> 
> J*fj)b?
> b??m????0?'?~???f??f??X??)ߣ?"?8b?X??+??DYׯzZ)????ay?+y">?-??%RǬ????W?z{h??,r?n???y۟???z?b?{(?˫???*T??"????'?~??~??{^??h?g???'????bq?b?zsip=