Subject: Re: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 5 Mar 2014 08:04:37 +0000

Hi 

If several DAS are producing realm OLRs, I think they have to ensure the consistency of the realm overload value they produced. Putting  a new Diameter Identity still adds complexity. Clients are not aware of the DAs deployed , they only know the peer DAs with which they have  a connection.  Then if a client receives two different realm overload reports from two DAS,  what does the client do with these two realm OLRs?

I would also remind a point I did in Porto: a client is aware of the overload or non overload of the different servers with which it has traffic, and can do an average (even weighted by the traffic it has with these servers) to infer a realm overload value that may be relevant when sending the requests with only realm destination. . This possibility should be allowed for me. I do not say it should be the only way as I am OK to have a realm OL coming from  DA that could be more accurate. 

Best regards

JJacques    

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de dime issue tracker
Envoyé : mercredi 26 février 2014 17:06
À : [email-masked]
Cc : [email-masked]
Objet : [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports

#58: Multiple Reporting Nodes for realm-routed-request type reports

 In deployments where more than one node is configured to take the role of  a reporting node for realm-routed-request reports, reacting nodes may  receive  in different answer messages different realm-routed-request type OLRs  inserted by the different reporting nodes. Although it is expected that  the different reporting nodes report more or less the same content, it  cannot be expected that reports are 100% synchronized. Especially sequence  numbers may differ.
 To allow reacting nodes correctly detect outdates/replays/freshness of  OLRs in this scenario, it is proposed that realm-routed-request type OLRs  are extended to contain the Diameter Identity of the reporting node that  inserted the realm-routed-request type OLR. (e.g. as already proposed in  draft-donovan-dime-agent-overload-01).
 Reporting nodes that insert realm-routed-request type OLRs to answer  messages MUST also insert their Diameter Identity.
 Reacting nodes MUST take the Diameter Identity received within the OLR  into account in order to detect outdates/replays/freshness.

-- 
-----------------------------------+--------------------------
 Reporter:  [email-masked]   |      Owner:  Ulrich Wiehe
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  draft-docdt-dime-ovli  |    Version:  1.0
 Severity:  Active WG Document     |   Keywords:
-----------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/58>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Wed, 5 Mar 2014 09:37:26 +0000

The response to this issue is simple: no realm indication if you cannot ensure that this info is valid for the entire realm.
Anything else is out of scope.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : mercredi 5 mars 2014 09:05
À : [email-masked]
Objet : Re: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports

Hi 

Best regards

JJacques    

-----Message d'origine-----

_________________________________________________________________________________________________________________________

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.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Mar 2014 09:54:23 +0000

JJacques,

Please see my comments inline.

Steve

> If several DAS are producing realm OLRs, I think they have to ensure the consistency of the realm overload value they produced. Putting  a new Diameter Identity still adds complexity. Clients are n…
SRD> It is clearly the case that we need wording on how to handle the
fact that Realm-Routed-Request (RRR) reports and the newly proposed
Realm reports can be sent from multiple places.  I'm preparing some
slides for use in the working group meeting to start to address this
point.  I'll put them on the mailing list when they are ready, probably
later today.

SRD> I have proposed that a reacting node only listen to one source of
the RRR and Realm reports for any overload occurrence.  This likely
requires including the source of the report in the report itself.  Can
you explain why it is an issue that a reacting node doesn't what about a
DA in advance of receiving the report?
> I would also remind a point I did in Porto: a client is aware of the overload or non overload of the different servers with which it has traffic, and can do an average (even weighted by the traffic…
SRD> Clients do not have a full view of the network, so relying on
clients to guess when the realm is very unlikely to ever work well for
networks of any real complexity.  That said, clients can clearly do so
if they want.  There is no protocol that needs to be defined as part of
DOIC to allow this to happen so it is out of scope for DOIC.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Mar 2014 16:02:16 +0000

> Anything else is out of scope.

+1. I don't think we care _how_, and don't need to specify it. If we decide we need to in the future, it can be a separate effort.