Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted

[<[e-mail]>]

> -----Message d'origine-----
> De : Vijay K. Gurbani [mailto:[e-mail]]
> Envoyé : mardi 8 février 2011 14:56
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [e-mail]
> Objet : Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted
> 
> On 02/08/2011 07:55 AM, [e-mail] wrote:
> > [BC] I was trying to find a solution for the case where the proxy has
> > been upgraded to support filtering of messages but not AS-A. I
> > believe this will frequently happen in real networks (e.g. AS-A is an
> > old system hosting basic telephony applications for user A while AS-B
> > is a new system hosting a new overload control sensitive application,
> > the core network proxies are upgraded).
> 
> Bruno: I see.  The thing that bothers me about this approach --- and I
> readily subscribe to your assertion that this may happen in real
> networks --- is that (a) we are essentially performing overload control
> for AS-B two hops away, and (b) we are attempting to codify B2BUA
> behaviour in the context of overload.
> 
> Even then, the proxy must have a filter so only those messages that
> AS-A will send to AS-B will be quenched.  What is the nature of this
> filter?  Is it prescribed anywhere?  Is loading this filter an
> administrative task or will AS-A automatically send it to the proxy?
> And if so, how?  These are all questions that arise in the context of
> your scenario.  To what extent do we need to flesh these out if we go
> this route?

[BC] That's a bit tricky indeed. I think I understand you point as well. May be we should just add a warning that filtering must be performed by the adjacent nodes or is this stated somewhere already?
> 
> > [BC] I agree under certain assumptions REQ-23 can be met. That's why
> > I think that "partial" is more suitable than "Yes". "Yes under
> > certain assumptions" would be fine as well.
> 
> I agree; that is probably the best we can do.  Unless someone else has
> any objections, I will update REQ-23 to read "Partial".
> 
> Thank you,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [e-mail]
> Web:   http://ect.bell-labs.com/who/vkg/