Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

[<[e-mail]>]

   REQ 16: The solution is likely to be deployed incrementally.  The
           solution MUST support a mixed environment where some, but not
           all, nodes implement it.

   REQ 18: In a mixed environment of nodes that support the solution and
           nodes that do not, the solution MUST NOT preclude elements
           that support overload control from treating elements that do
           not support overload control in an equitable fashion relative
           to those that do.  Users and operators of nodes that do not
           support the solution MUST NOT unfairly benefit from the
           solution.  The solution specification SHOULD provide guidance
           to implementors for dealing with elements not supporting
           overload control.

Theses requirements are also fulfilled if servers or agents are able to handle clients that do not support DOIC and if client and agents are able to react to implicit overload indication received from the network.

In summary, I really don't see what is missing.

Lionel


-----Message d'origine-----
De : Ben Campbell [mailto:[e-mail]] 
Envoyé : vendredi 14 février 2014 23:07
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : MORAND Lionel IMT/OLN; ext Steve Donovan; [e-mail]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages


On Feb 14, 2014, at 8:59 AM, Wiehe, Ulrich (NSN - DE/Munich) <[e-mail]> wrote:

> I think that two points are mixed:
> 
> 1) For efficiency, a DOIC-enabled client should be able to mitigate (possible) overload situation even if explicit indication is not received from the network.
> 2) DOIC-enabled clients having a different behavior regarding support or not of DOIC by server.
> 
> if I agree with the first one, I disagree with the second one. The basic assumption is that a DOIC client will not throttle the traffic in absence of overload indication (explicit or implicit). And throttling will be performed as soon as an indication is received (explicit or implicit) if the client is designed for that (it supports DOIC or/and default behavior has been defined on reception of TOO_BUSY or non-response).
> 
> It is the only thing that matters today.

I disagree, for  reasons stated earlier. In summary, the requirement that reacting nodes be able to take different action depending on whether an opposite endpoint supports DOIC is a direct implication of requirements 16 and 18 of RFC 7068.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.