[Serusers] [Serdev] loose_route behaviour, detecting single Route with myself

[Jiri Kuthan]

At 11:52 17/07/2007, Martin Hoffmann wrote:
>Jiri Kuthan wrote:
>> At 16:18 16/07/2007, Klaus Darilion wrote:
>> >> |
>> >> |      o  A stateless proxy MUST choose one and only one target from the
>> >> |         target set.  This choice MUST only rely on fields in the
>> >> |         message and time-invariant properties of the server.  In
>> >> |         particular, a retransmitted request MUST be forwarded to the
>> >> |         same destination each time it is processed.  Furthermore,
>> >> |         CANCEL and non-Routed ACK requests MUST generate the same
>> >> |         choice as their associated INVITE.
>> >
>> >That would mean that doing lookup() in a stateless proxy is practically 
>> >not allowed.
>> 
>> That's indeed what Martin suggested. The spec is vague in this, the idea in it
>> is that retransmissions don't get 'forked' if usrloc entry changes. That 
>> basically means there cannot be a statelss proxy unless it never changes
>> its routing data :-) Sound a bit like an overstandardization to me.
>
>I tend to disagree.
> This bullet effectively limits stateless proxies to
>load balancers and other rather static cases. 

Yes. (Or if you read it rigirously, it limites the use case to load-balancers
that never change the list of load-balanced servers :-)))

>IMHO it's the authors' way
>of saying "Don't do stateless proxying." Many have tryied nonetheless
>and, oh wonder, many have failed. Statless proxying is broken. There is
>too many tripfalls.

I agree authors said that, but I'm not sure they realized completely what
they have said and I think they went too far with it. Despite all possible
corner-cases, stateless-forwarding has been deployed and worked, paritcularly
for sake of load-balancing. I'm personally opposed against generally banning
stateless forwarding (even though it is not the mainstream case).


>> (I hope
>> I don't offend those on mailing list, who consider RFC3261 too axiomatically.)
>
>Well, it is not obviously broken at this point, so it shall be followed.

My point is it actually is, because it effectively mandates state usage, wherease
there are valid scenarios which rely on the stateless mode. (not sure actually
what is the sense of defining and banning a stateless proxy in the same document :-))

> 
>> If one had a well articulated case for stateless proxy with userloc (does anyone 
>> have such?), I would not hesitate to do it. We have done such things in the
>> past, note for example that in default configuration SER's registrat is
>> stateless. This is tremendously important because of performance implications.
>> Nevertheless, if you look at the RFC3261, it actually says that the UAS
>> should be stateful in such case.
>
>Haven't searched too thoroughly, but does it actually say somewhere
>"registrar MUST be statefull".

Exactly my point -- overstandardized.


>> Here we traded a minor consistency issue
>> against a significant performance gain.
>
>Did you now? We've been through this, but the statelessness actually
>killed my registrars quite regularly when coming under heavy load. That
>got fixed (for a while, anyways) by making the registrar stateful.
>The heavy part of processing a REGISTER is _not_ the transaction
>handling.

I would prefer not to generalize a specific error. Whereas for example
a DB architecture may overshadow transaction processing overhead, 
a properly cached architecture moves the next shock space to TM.
Under abnormal situations this is the next bottleneck.

-jiri