Subject: [Sip] PUBLISH message rates

From: Adam Roach <[email-masked]>
Date: Wed, 12 Nov 2003 14:00:10 -0600

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Nov 2003 15:25:16 -0500

To amplify the third point: Since multiple entities may publish for the 
same presentity, for example, the NOTIFY rate may be as high as the sum 
of the PUBLISH rates. Thus, restricting PUBLISH cannot be relied upon to 
limit the NOTIFY rate, since the different PUBLISH sources presumably 
have no idea what others have been up to.

Thus, requiring some max. PUBLISH rate is not likely to be effective, 
but may be harmful in some (future) scenarios.

---

From: "Ashir Ahmed" <[email-masked]>
Date: Thu, 13 Nov 2003 06:13:29 +0900

Is there any ways that the PUA know about the watcher's request?
Why do I care?
I have a mobile phone ( a PUA). I don't want to pay money for PUBLISHing
unnecessary information. Besides the frequency of  PUBLISH, there is another
concern about the volume of  PUBLISH. So, if the PUA have the information
about the watcher's request (WHAT and when (the frequency) is being
subscribed), the PUA can respond accordingly.

ashir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Henning
Schulzrinne
Sent: Thursday, November 13, 2003 5:25 AM
To: Adam Roach
Cc: [email-masked]'
Subject: Re: [Sip] PUBLISH message rates

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Nov 2003 16:58:12 -0500

> subscribed), the PUA can respond accordingly.

Unless you have a very special situation in mind, the number of watchers 
is typically large. You would have to compute the max. desired rate 
across all watchers and in addition take into account the filters they 
may have installed. Since you're paying, you should just update the 
presence information when you feel like it. After all, you're providing 
the service (typically) for free.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Nov 2003 21:28:55 -0600

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.

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 02:18:28 -0500

> have no idea what others have been up to.

I didnt think the intent was to use a limit on the PUBLISH rate to 
enforce the limit on the NOTIFY rate.

I think the point was that, if we believed there was value in limiting 
the NOTIFY rate (and we do, according to rfc3265), there is probably 
value in limiting the PUBLISH rate too.

I dont feel that strongly about this, since I think its a non-issue 
practically speaking until we have packages that really push limits. 
Before we get there, its mostly an academic exercise.

In that case, I am inclined to go for consistency, and have PUBLISH 
limited in rate as NOTIFYs are within a package.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Nov 2003 11:01:52 -0500

We should look at the motivation for the rate limitation. It can't be 
transport - that's a separate problem. There is some justification for 
limiting NOTIFYs since these are directed to devices that have a loose 
relationship to the PA. Also, these devices may have limited 
capabilities and may not be ready to receive 100 notifications/second.

However, in most cases of interest, the PA and the publisher are closely 
related. In addition, since the end system has complete control over the 
rate of sending PUBLISH, the 'protect low-end end systems' arguments 
doesn't apply.

I don't see why a spec should proscribe how often my UA and my PA can 
talk to each other. I'm not aware of any other Internet application 
protocol that makes such recommendations. We don't have a spec that says 
that you have to limit your SMTP rate to your outbound MTA to a certain 
value.

I'm philosophically opposed to "pulled out of thin air" recommendations 
that are ineffective and have no engineering basis.

Jonathan Rosenberg wrote:
>> To amplify the third point: Since multiple entities may publish for 
>> the same presentity, for example, the NOTIFY rate may be as high as 
>> the sum of the PUBLISH rates. Thus, restricting PUBLISH cannot be 
>> relied upon to limit the NOTIFY rate, since the different PUBLISH 
>> sources presumably have no idea what others have been up to.
> 
> 

But why else tie the two rates in any way?

---

From: Aki Niemi <[email-masked]>
Date: Thu, 13 Nov 2003 18:43:58 +0200

> capabilities and may not be ready to receive 100 notifications/second.

Even this isn't solved using the default rate limit in notifications, 
because it will only apply to a single notifier. Typically, an endpoint 
has many active subscriptions, so the aggregate rate may still be 
considerable. The event-throttle work attempts to address this.

> rate of sending PUBLISH, the 'protect low-end end systems' arguments 

Right, it would mainly be about protecting the SIP routing fabric and 
the composer.

> that are ineffective and have no engineering basis.

I guess these recommendations would anyway be "hand-waiving" with or 
without a hard rate limit recommendations. It's not like the rate could 
ever really be enforced in a meaningful way.

I think we can agree that documenting this issue is a good thing. Also, 
I would say explaining how a composer can use the SIP level push-back 
should be in the draft. Whether to have a concrete rate limit or not, 
I'm ok either way. I can suggest text that has a SHOULD strength 
recommendation that publishing EPAs pay attention to the rate at which 
they send updates.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Nov 2003 12:00:51 -0500

> considerable. The event-throttle work attempts to address this.

True (and somewhat beyond the topic of this discussion). One could 
defend the rate limit in the NOTIFY case in arguing that at least the 
poor resource-constrained UA knows that it is subscribing to N events 
and thus can upperbound the event rate by summing them up. The PA can't, 
since it has generally no way of knowing how many entities will publish 
for a single event.

> 
>> However, in most cases of interest, the PA and the publisher are 
>> closely related. In addition, since the end system has complete 
>> control over the rate of sending PUBLISH, the 'protect low-end end 
>> systems' arguments doesn't apply.
> 
> 

Since it doesn't in any way limit the aggregate rate, this is a very 
loose way to protect anything. As noted, we don't limit the individual 
rate of sending email in the Internet by protocol spec to protect the 
aggregate MTA population. (Obviously, individual ISPs do sometimes apply 
rate limits for email submission to keep spammers out of their network, 
but that's a local policy decision, not a protocol decision.)

> ever really be enforced in a meaningful way.

We have Congress to pass meaningless declarations of good intent, so no 
need for the IETF to get into that business :-)

> recommendation that publishing EPAs pay attention to the rate at which 

My basic test for any protocol spec normative statement is whether I can 
tell if somebody is violating the spec by observing external behavior. 
I'm unclear how I can measure 'paying attention' - I have a hard enough 
time with telling whether my students are ...