Subject: RE: [Sip] PUBLISH message rates

From: [email-masked]
Date: Tue, 25 Nov 2003 18:41:10 +0200

Hi Paul,

 > -----Original Message-----
 > From: ext Paul Kyzivat [mailto:[email-masked]]
 > Sent: 14 November, 2003 16:30
 > To: Henning Schulzrinne
 > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
 > [email-masked]; [email-masked]; [email-masked]
 > Subject: Re: [Sip] PUBLISH message rates
 > 
 > 
 > 
 > 
 > > [email-masked] wrote:
 > > 
 > >> The only way to do this right is to do what RTCP does with report
 > >> interval, and that is to adjust the rate of PUBLISH using some
 > >> formula that takes into account the number of publishers 
 > at a given
 > >> time. The more publishers that join, the less the rate at which
 > >> PUBLISH is sent at. The compositors need to communicate that
 > >> calculated rate to the publishers somehow. Do we want to 
 > make it that
 > >> complicated? If not, then I suggest adding text the says if the
 > >> compositor is overloaded, it can send a 5xx response with
 > >> retry-after.
 > 
 > Of course use of 5xx with retry-after wastes the effort the 
 > compositor 
 > has already expended in processing the publish up to that point.
 > 
 > It might be interesting to make a change permitting use of the 
 > Retry-After header with a 2xx response. Then the compositor 
 > could accept 
 >   a publish and at the same time ensure that the next one 
 > doesn't come 
 > too soon. This wouldn't be useful in all cases, but maybe in some.

I think this is an interesting idea. However, it doesn't seem to quite fit the Retry-After meaning. After all, the request did succeed since it received a 200 OK. 

Cheers,
Aki

 > 	Paul

_______________________________________________
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: Tue, 25 Nov 2003 11:51:39 -0500

[Trimming the cc ballast]

> I think this is an interesting idea. However, it doesn't seem to
> quite fit the Retry-After meaning. After all, the request did succeed
> since it received a 200 OK.

I think general SIP design philosophy is to avoid overloading of 
distinct meanings on the same parameter. We don't want to have to say 
'if the moon is in the first quarter, header Foo means that, but 
otherwise it means something different'. If this is valuable, then it 
deserves its own header field.

The particular approach also has the problem of introducing additional 
error cases and state: "sorry, PUBLISH, you were 5 seconds too early, 
please try again in 5 seconds".

That said, I share the doubts raised that any unconditional and 
content-unaware filtering is all that useful in practice.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Nov 2003 16:26:33 -0500

> deserves its own header field.

I agree that bundling Retry-After with a 2xx response is kind of zany, 
and there are probably better ways to solve the problem.

> content-unaware filtering is all that useful in practice.

At least when the problem is pushed back to the publisher (however that 
is achieved),  it is in the best position to deal with the problem in an 
intelligent way.

Adam Roach wrote:
> 
> I think you're starting down the same path that Robert has already
> put some good work into. You probably want to take a look at:
> 
> http://www.ietf.org/internet-drafts/draft-sparks-sipping-load-00.txt

Yes, this is clearly a special case of what Robert is talking about, and 
he has put way more thought into it than I did.

One difference - I *think* robert is trying to put pressure on a source 
to slow down everything from it. But maybe the pressure needs to be more 
selective, as in: slow down the PUBLISH requests, but its still ok to 
send an INVITE right away.

Of course that also makes an already intractible problem even harder. I 
have the feeling we are just groping in the dark here, but maybe that is 
how it has to start.

	Paul