Subject: [Dime] Updates to DOIC -05

From: Steve Donovan <[email-masked]>
Date: Mon, 03 Nov 2014 08:35:34 -0600

All,

I have done another end-to-end read of the DOIC specification, focusing 
on wording, consistency and removing any remaining redundancy in the 
document.

I have pushed the changes into github.

I have attached the diff to this email.

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Sun, 9 Nov 2014 01:16:55 +0000

Steve, all,

See some comments included in attached doc.
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 03 de noviembre de 2014 15:36
To: [email-masked]
Subject: [Dime] Updates to DOIC -05

All,

I have done another end-to-end read of the DOIC specification, focusing on wording, consistency and removing any remaining redundancy in the document.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 10 Nov 2014 15:34:34 +0000

Sreve, MCruz, all,

please find more comments attached.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Sunday, November 09, 2014 2:17 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve, all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 03 de noviembre de 2014 15:36
To: [email-masked]
Subject: [Dime] Updates to DOIC -05

All,

Regards,

Steve

---

From: <[email-masked]>
Date: Mon, 10 Nov 2014 16:49:19 +0000

Hi Ulrich and María Cruz,

Please stop commenting through attached documents, requested several times and explained again yesterday by Ben. Some people may not be able to read at all the attached documents and it makes impossible parsing mechanism in the mailing list and in the archives.

Please write your comments directly in the email.

Thank you.

lionel

Envoyé depuis mon Sony Xperia SP d'Orange

---- Wiehe, Ulrich (NSN - DE/Munich) a écrit ----

Sreve, MCruz, all,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Sunday, November 09, 2014 2:17 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve, all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 03 de noviembre de 2014 15:36
To: [email-masked]
Subject: [Dime] Updates to DOIC -05

All,

Regards,

Steve

_________________________________________________________________________________________________________________________

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: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Nov 2014 12:46:33 +0000

Lionel,
I am very sorry.

Some of my comments are immediate reactions to MCruz's comments. I do not repeat those here (assuming that people who can read MCruz's comments can also read my reaction, while people who cannot will not be able to understand my reaction anyway as it would be out of context).
Please find other comments below.

Ulrich

Section 3, 4th paragraph from end, 2nd sentence:
Existing text: For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send requests to other destinations or via other agents.
Proposed text: For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send requests to other destinations or - if agent overload control is supported (Section A.2) - via other agents.

Section 3, last paragraph, 3rd sentence from end:
Existing text:
For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unchanged.
Proposed text: For example, one or more Diameter agents that do or do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass OC-specific AVPs or unknown AVPs through unchanged.

Section 3.2, 3rd paragraph last sentence:
Existing text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. 
Proposed text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting node in the path of the request.

Section 3.2, 2nd paragraph from end, 2nd sentence:
Existing text: In this case, the agent updates the OC-Supported-Feature AVP to reflect the mixture of the two sets of supported features.
Proposed text: In this case, the agent can replace the OC-Supported-Features AVP (which indicates the features supported by the downstream reacting node) with its own OC-Supported-Feature AVP (which indicates the features supported by the agent). By doing so, the agent takes the role of a reporting node (reporting towards the downstream reacting node) and at the same time takes the role of a reacting node (reacting on OLRs received from upstream reporting nodes). 

Section 4.1.3, 1st paragraph, 1st sentence:
Existing text: Diameter agents that support DOIC SHOULD ensure that all messages have the OC-Supporting-Features AVP.
Proposed text: Diameter agents that support DOIC SHOULD ensure that all request messages have the OC-Supported-Features AVP.

Section 4.1.3, 1st paragraph, 2nd sentence:
Existing text: If a message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP.
Proposed text: If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. 

Section 4.1.3, 3rd paragraph, 1st sentence:
Existing text: If the message already has the OC-Supported-Features AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect a mixed set of DOIC features.
Proposed text: If the request message already has the OC-Supported-Features AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect the agent's set of supported DOIC features.

Section 4.1.3, 5th paragraph, 1st sentence:
Existing text: An agent MAY modify the OC-Supported-Features AVP carried in answer messages.
Proposed text: An agent MAY replace the OC-Supported-Features AVP carried in answer messages (which indicates the features supported/selected by the upstream reporting node) with its own OC-Supported-Feature AVP (which indicates the features supported/selected by the agent).

Section 4.2.3, 13th paragraph, 2nd sentence:
Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies.
Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies.

Section 6.5, 1st paragraph, 5th sentence
Existing text: Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used.
Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours) MUST NOT be used.    

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 10, 2014 5:49 PM
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]; Wiehe, Ulrich (NSN - DE/Munich)
Subject: Re: [Dime] Updates to DOIC -05

Thank you.

lionel

---- Wiehe, Ulrich (NSN - DE/Munich) a écrit ----

Sreve, MCruz, all,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Sunday, November 09, 2014 2:17 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve, all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 03 de noviembre de 2014 15:36
To: [email-masked]
Subject: [Dime] Updates to DOIC -05

All,

Regards,

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 11 Nov 2014 15:24:16 +0200

Steve,

Thanks for the updated version. There are few long standing editorials 
e.g. in Sections 4.2.1.1., 4.2.1.3 that should be corrected.

In Section 4.2.1.1:

OLD:
A host-type OCS entry is identified by the pair of Application-Id and
Host-Id.

NEW:
A host-type OCS entry is identified by the pair of application-id and
node's DiameterIdentity.

OLD:
A realm-type OCS entry is identified by the pair of Application-Id
and Realm-Id.

NEW:
A realm-type OCS entry is identified by the pair of application-id
and realm.

In Section 4.2.1.3.

OLD:
For a host report-type this means it matches the app-id and host-id
in an existing host OCS entry.

NEW:
For a host report-type this means it matches the application-id and 
host's DiameterIdentity in an existing host OCS entry.

OLD:
For a realm report-type this means it matches the app-id and realm-id
in an existing realm OCS entry.

NEW:
For a realm report-type this means it matches the application-id and the 
realm in an existing realm OCS entry.

OLD:
For a host report-type this means it creates on OCS entry with the
app-id of the application-id in the received message and host-id of
the Origin-Host in the received message.

NEW:
For a host report-type this means it creates on OCS entry with the
application-id in the received message and DiameterIdentity of the
Origin-Host in the received message.

OLD:
For a realm report-type this means it creates on OCS entry with the
app-id of the application-id in the received message and realm-id of
the Origin-Realm in the received message.

NEW:
For a realm report-type this means it creates on OCS entry with the
application-id in the received message and realm of the Origin-Realm
in the received message.

Actually.. when we talk about the "realm" in the context of 
Origin-Realm, tchnically we should still be talk about DiameterIdentity. 
However, I am ok just saying "realm" here.

- Jouni

11/3/2014 4:35 PM, Steve Donovan kirjoitti:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 11 Nov 2014 05:11:03 -1000

Maria Cruz,

Would it be possible for you to break out the comments that you think 
need group discussion, especially those that Ulrich commented on in the 
word document he sent?

Then we can work through the list of issues known issues in the issue 
tracker and in editor notes in the document plus new issues sent by you, 
Ulrich, Jouni and Ben.

Thanks,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Nov 2014 16:58:37 +0000

Steve, all,

See below the comments that may require some group discussion:

Ch 2:

Now:
   Diversion

      Abatement of traffic sent to a reporting node by a reacting node
      in response to receipt of an overload report.  The abatement is
      achieved by diverting traffic from the reporting node to another
      Diameter node that is able to process the request.

Proposal:

   Diversion

      Abatement of traffic sent to a reporting node performed by a reacting n.  The abatement is
      achieved by diverting (?) traffic from the reporting node to a less overloaded
      Diameter node that is able to process the request, based on received overload report(s).

?: any better word to avoid using "diverting" when we are defining "diversion"?

Ch 2:
Now:
Overload Report (OLR)

      Information sent by a reporting node indicating the start,
      continuation or end   of an occurrence of overload control.

Proposed:
Overload Report (OLR)

      Information sent by a reporting node about its overload situation.

Ch2
Now
   Reacting Node

      A Diameter node that receives and acts upon an overload report.

Proposed:
   Reacting Node

      A Diameter node that acts upon an overload report.

Ch2:
Now
   Throttling

      Abatement of traffic sent to a reporting node by dropping or
      rejecting Diameter requests.  Throttling can include a Diameter
      Client or Diameter Server dropping requests, or a Diameter Agent
      rejecting requests with appropriate error responses.  In extreme
      cases reporting nodes can also throttle requests when the
      requested reductions in traffic does not sufficiently address the
      overload scenario.

Proposed:
   Throttling

      Abatement of traffic by dropping or
      rejecting Diameter requests.  Throttling can include a Diameter
      Client or Diameter Server dropping requests, or a Diameter Agent
      rejecting requests with appropriate error responses (?).  In extreme
      cases reporting nodes can also throttle (or drop) requests when the
      requested reductions in traffic does not sufficiently address the
      overload scenario.

?: Question: do we consider an agent is not allowed to DROP a request?

Ch3
Now:
A Diameter node that supports DOIC is known as a "DOIC node".  Any
   Diameter node can act as a DOIC node, including clients, servers, and
   agents.  DOIC nodes are further divided into "Reporting Nodes" and
   "Reacting Nodes."  A reporting node requests overload abatement by
   sending an Overload Report (OLR) to one or more reacting nodes .

Proposed:
A Diameter node that supports DOIC is known as a "DOIC node".  Any
   Diameter node can act as a DOIC node, including clients, servers, and
   agents.  DOIC nodes are further divided into "Reporting Nodes" and
   "Reacting Nodes."  A reporting node requests overload abatement by
   sending an Overload Report (OLR) to a reacting node.

Ch3. Question:

   A reacting node acts upon OLRs, and performs whatever actions are
   needed to fulfil the abatement requests included in the OLRs.  A
   Reporting node may report overload on its own behalf, or on behalf of
   other (typically upstream ??) nodes.  Likewise, a reacting node may
   perform overload abatement on its own behalf, or on behalf of other
   (typically downstream?? ) nodes.

"Typically"? is any other possibility?

Ch3: modification and question

Now:

   A Diameter node's role as a DOIC node is independent of its Diameter
   role.  For example, Diameter Relay  and Proxy Agents may act as DOIC
   nodes, even though they are not endpoints in the Diameter sense.
   Since Diameter enables bi-directional applications, where Diameter
   Servers can send requests towards Diameter Clients, a given Diameter
   nodes can simultaneously act as a reporting node and a reacting node

Proposed:

   A Diameter node's role as a DOIC node is independent of its Diameter
   role.  For example, Diameter Relay  (?) and Proxy Agents may act as DOIC
   nodes, even though they are not endpoints in the Diameter sense.
   Since Diameter enables bi-directional applications, where Diameter
   Servers can send requests towards Diameter Clients, those Diameter
   nodes can simultaneously act as a reporting node and a reacting node.

Can a Relay be a DOIC node? Since by definition is application-less? If DOIC-enabled, can it be considered a "relay" any longer?
We had this discussion before, but not sure whether we reached a conclusion.

Ch3
Now:
   Reacting nodes perform overload abatement according to an agreed-upon
   abatement algorithm.  An abatement algorithm defines the meaning of
   the parameters of an OLR and the procedures required for overload
   abatement.  This document specifies a single must-support algorithm,
   namely the "loss" algorithm (Section 5).  Future specifications may
   introduce new algorithms.

Proposed:
   Reacting nodes perform overload abatement according to an agreed-upon
   abatement algorithm.  An abatement algorithm may defines the meaning of
   some of the parameters of an OLR and the procedures required for overload
   abatement.  This document specifies a single must-support algorithm,
   namely the "loss" algorithm (Section 5).  Future specifications may
   introduce new algorithms.

4.2.1.2.  Overload Control State for Reporting Nodes

Now:
   A reporting node SHOULD maintain OCS entries per supported Diameter
   application, per supported (and eventually selected) Abatement
   Algorithm and per report-type.

   An OCS entry is identified by the pair of Application-Id and
   Abatement Algorithm.

   The OCS entry for a given pair of Application and Abatement Algorithm
   MAY include the information (the actual information stored is an
   implementation decision):

   o  Report type

   o  Sequence number

   o  Validity Duration

   o  Expiration Time

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

Proposed:
   A reporting node SHOULD maintain OCS entries per supported Diameter
   application, per supported (and eventually selected) Abatement
   Algorithm and per report-type.

   An OCS entry is identified by the pair of Application-Id, 
   Abatement Algorithm and Report Type and MAY include the following information (the actual information stored is an
   implementation decision):

   o  Sequence number

   o  Validity Duration

   o  Expiration Time

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

4.2.1.4  
Question on following paragraph:
      If the reporting node knows that the OCS entries in the reacting
      nodes are near expiration then the reporting node can decide to
      delete the OCS entry.

This paragraph is unclear to me.
"knows that the OCS entries in the reacting"?
"decide to delete the OCS entry"?
Could you clarify what was the intention?

5.3
Now:
   It is suggested that the reacting node decrease the amount of traffic
   given abatement treatment by 20% each second  until the reduction is
   completely removed and no traffic is given abatement treatment.

Proposed:
   It is suggested that the reacting node decrease progressively the amount of traffic
   given abatement treatment until the reduction is
   completely removed and no traffic is given abatement treatment.

Justification:
Not sure we have discussed the reasoning for this value.
And it may not be applicable to all overload occurrences and traffic rates.

6.8
Remove:
Otherwise, when reused in newly
   defined Diameter applications, the DOC related AVPs SHOULD have the
   M-bit set.

And refer 6733 RFC.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: martes, 11 de noviembre de 2014 16:11
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Maria Cruz,

Would it be possible for you to break out the comments that you think need group discussion, especially those that Ulrich commented on in the word document he sent?

Then we can work through the list of issues known issues in the issue tracker and in editor notes in the document plus new issues sent by you, Ulrich, Jouni and Ben.

Thanks,

Steve

---

From: <[email-masked]>
Date: Tue, 11 Nov 2014 17:59:55 +0000

Thank you, Ulrich.

Lionel

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : mardi 11 novembre 2014 13:47
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; Steve Donovan; [email-masked]
Objet : RE: [Dime] Updates to DOIC -05

Lionel,
I am very sorry.

Ulrich

Section 6.5, 1st paragraph, 5th sentence Existing text: Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used.
Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours) MUST NOT be used.    

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, November 10, 2014 5:49 PM
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]; Wiehe, Ulrich (NSN - DE/Munich)
Subject: Re: [Dime] Updates to DOIC -05

Thank you.

lionel

---- Wiehe, Ulrich (NSN - DE/Munich) a écrit ----

Sreve, MCruz, all,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Sunday, November 09, 2014 2:17 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve, all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 03 de noviembre de 2014 15:36
To: [email-masked]
Subject: [Dime] Updates to DOIC -05

All,

Regards,

Steve

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: <[email-masked]>
Date: Tue, 11 Nov 2014 18:39:05 +0000

Thank you, Maria Cruz

All, Please see below.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mardi 11 novembre 2014 17:59
À : Steve Donovan; [email-masked]
Objet : Re: [Dime] Updates to DOIC -05

Steve, all,

Ch 2:

Now:
   Diversion

Proposal:

   Diversion

[LM] Diversion by definition is not an abatement method. In the context of Diameter, it is forcing the request traffic toward an alternative peer. One of the reasons for this diversion can be overload of the primary selected peer (identified in the Desination-host or selected by the forwarding node). But it is only of the reasons. If it required to restrict the definition in this document, we could define a "an Abatement by diversion".

Ch 2:
Now:
Overload Report (OLR)

Proposed:
Overload Report (OLR)

[LM] ok

Ch2
Now
   Reacting Node

Proposed:
   Reacting Node

[LM] ok

Ch2:
Now
   Throttling

Proposed:
   Throttling

[LM] Again, throttling is not link to abatement. Throttling refers to a limit of the number of messages sent or forwarded by a Diameter node. But this limit can be set based on operator policy and not due to overload. See if only a definition of throttling is required or a definition of "abatement by throttling".

Ch3
Now:

Proposed:

[LM] ok

Ch3. Question:

[LM] I would propose to just remove "typically upstream/downstream".

Now:

Proposed:

[LM] and the conclusion is that a Diameter Relay "by definition i.e. RFC6733" is application-agnostic and not able to act on received OLR. If you want to get rid of the discussion, we can say "diameter agents" here, without further distinction

Ch3
Now:

Proposed:

[LM] ok

Now:

   o  Report type

   o  Sequence number

   o  Validity Duration

   o  Expiration Time

Proposed:

   o  Sequence number

   o  Validity Duration

   o  Expiration Time

[LM] ok

4.2.1.4  

5.3
Now:

Proposed:

Justification:

[LM] agree

6.8
Remove:

And refer 6733 RFC.

[LM] as decided in the interim meeting.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: martes, 11 de noviembre de 2014 16:11
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Maria Cruz,

Thanks,

Steve

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 02:12:38 +0000

Please see below.
Forgot to attached my comments :)
Regards,
Lionel
------

Thank you, Ulrich.

Lionel

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] Envoyé : mardi 11 novembre 2014 13:47 À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; Steve Donovan; [email-masked] Objet : RE: [Dime] Updates to DOIC -05

Lionel,
I am very sorry.

Ulrich

[LM] Not sure to understand the need for support of Agent overload for that...

[LM] but actually, "OC-Specific AVPs" are unknown for a non-supporting agent.

[LM] I may be too tired, but I cannot see the proposed change.

[LM] will be discussed in a separate mail.

[LM] ok

[LM] ok

[LM] ok

[LM] discussed in a separate mail.

[LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS.

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, November 10, 2014 5:49 PM
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]; Wiehe, Ulrich (NSN - DE/Munich)
Subject: Re: [Dime] Updates to DOIC -05

Thank you.

lionel

---- Wiehe, Ulrich (NSN - DE/Munich) a écrit ----

Sreve, MCruz, all,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Sunday, November 09, 2014 2:17 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve, all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 03 de noviembre de 2014 15:36
To: [email-masked]
Subject: [Dime] Updates to DOIC -05

All,

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Nov 2014 13:00:09 +0000

Lionel,

please see inline.

Best regards
Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2014 3:13 AM
To: MORAND Lionel IMT/OLN; Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; Steve Donovan; [email-masked]
Subject: RE: [Dime] Updates to DOIC -05

Please see below.

Thank you, Ulrich.

Lionel

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

Lionel,
I am very sorry.

Ulrich

[LM] Not sure to understand the need for support of Agent overload for that...
[Ulrich] In the absence of agent overload control it is always the server or realm that is overloaded and then it is not reasonable to attempt sending requests via other agents to the same overloaded server or realm.

[LM] but actually, "OC-Specific AVPs" are unknown for a non-supporting agent.
[Ulrich] yes, but the exist text does not cover the case where a DOIC supporting agent exists between a given pair of reporting and reacting nodes, which passes OC-specific AVPs (although not unknown) through unchanged.

[LM] I may be too tired, but I cannot see the proposed change.
[Ulrich] That's why I like revision marking in word documents. Try again.

[LM] ok

[LM] ok

[LM] ok

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, November 10, 2014 5:49 PM
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]; Wiehe, Ulrich (NSN - DE/Munich)
Subject: Re: [Dime] Updates to DOIC -05

Thank you.

lionel

---- Wiehe, Ulrich (NSN - DE/Munich) a écrit ----

Sreve, MCruz, all,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Sunday, November 09, 2014 2:17 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve, all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 03 de noviembre de 2014 15:36
To: [email-masked]
Subject: [Dime] Updates to DOIC -05

All,

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Nov 2014 14:31:51 +0000

Maria Cruz,
please see below.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, November 11, 2014 5:59 PM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve, all,

Ch 2:

Now:
   Diversion

Proposal:

   Diversion

Ch 2:
Now:
Overload Report (OLR)

Proposed:
Overload Report (OLR)

      Information sent by a reporting node about its overload situation.
[Ulrich] I better like the old text as it covers also cases where an agent reports realm-overload.

Ch2
Now
   Reacting Node

Proposed:
   Reacting Node

      A Diameter node that acts upon an overload report.
[Ulrich] What is wrong with the existing text?

Ch2:
Now
   Throttling

Proposed:
   Throttling

[Ulrich] yes

Ch3
Now:

Proposed:

[Ulrich] What is wrong with the existing text?

Ch3. Question:

Now:

Proposed:

Ch3
Now:

Proposed:

[Ulrich] What is wrong with the existing text?

Now:

   o  Report type

   o  Sequence number

   o  Validity Duration

   o  Expiration Time

Proposed:

   o  Sequence number

   o  Validity Duration

   o  Expiration Time

[Ulrich] ok, but then it is no longer a pair but a triplet

4.2.1.4  

5.3
Now:

Proposed:

Justification:

6.8
Remove:

And refer 6733 RFC.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: martes, 11 de noviembre de 2014 16:11
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Maria Cruz,

Thanks,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 12 Nov 2014 08:32:27 -1000

The suggestion is from "reacting nodes" to "reacting node".

I disagree with this change, as there can be more than one reacting node 
for a single report.

I would agree to change it to "reacting node(s)".

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 13 Nov 2014 08:48:26 +0000

Steve,

I strongly disagree.

In the path of a request there are allways as many reacting nodes as reporting nodes.

Examples are:
1. one reporting node, one reacting node
+---+       +---+      +---+
| C |-------| A |------| S |
+---+       +---+      +---+
C is reacting node (reacting on host-type OLRs received from S),
A (no matter whether or not it supports DOIC) is neither reacting node nor reporting node,
S is reporting node
C and S must have at least one commonly supported algorithm.

2. one reporting node, one reacting node
+---+       +---+      +---+
| C |-------| A |------| S |
+---+       +---+      +---+
C is neither reacting node nor reporting node,
A is reacting node (on behalf of C),
S is reporting node
A and S must have at least one commonly supported algorithm.

3. two reporting nodes, two reacting nodes
+---+       +---+      +---+
| C |-------| A |------| S |
+---+       +---+      +---+
C is reacting node (reacting on realm-type OLRs received from A),
A is reporting node (reporting realm-type OLRs to C) and reacting node (reacting on host-type OLRs received from S) 
S is reporting node
C and A must have at least one commonly supported algorithm, and A and S must have at least one commonly supported algorithm. No need for C, A, and S to have at least one commonly supported algorithm.

What we DO NOT have is:
4. one reporting node, two reacting nodes
+---+       +---+      +---+
| C |-------| A |------| S |
+---+       +---+      +---+
C is reacting node,
A is reacting node but not reporting node, 
S is reporting node
If we had this then yes 
There would be the need for C, A, and S to have at least one commonly supported algorithm, and
There would be the need to modify the algorithm negotiation mechanism: e.g. when C supports loss, A supports loss and rate, S supports loss and rate, then A would not be allowed to advertize rate and loss to S but only loss. 

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2014 7:32 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Updates to DOIC -05

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 13 Nov 2014 06:53:45 -1000

Ulrich,

The basic scenario, when there are agents between Diameter Clients and 
Diameter Servers, for handling of host reports requires two separate 
Diameter nodes to act on the host report.

The client in your first case is responsible for applying abatement 
treatment to host routed requests.

The agent is responsible for applying abatement treatment to realm 
routed requests.

As such, there can be more than one reacting node for a single overload 
report.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 13 Nov 2014 08:49:38 -1000

Ulrich,

Please see inline.

Steve

> [Ulrich] In the absence of agent overload control it is always the server or realm that is overloaded and then it is not reasonable to attempt sending requests via other agents to the same overload…
SRD> Agent overload isn't yet defined so we can't refer to it in this 
document.  I also perfectly ok, in fact, it is expected behavior, for a 
reacting node for a host report to send realm routed requests to a 
different agent as the reacting node does not know which host will end 
up handling the request.
> [Ulrich] yes, but the exist text does not cover the case where a DOIC supporting agent exists between a given pair of reporting and reacting nodes, which passes OC-specific AVPs (although not unkno…
SRD> I disagree with the change.  We have already identified cases where 
a DOIC agent can change the OC-specific AVPs.
> [Ulrich] That's why I like revision marking in word documents. Try again.
SRD> This is addressed in a separate email.
> [LM] will be discussed in a separate mail.
SRD> We discussed this is the working group meeting this week. The text 
will be updated to indicate that agents can modify the 
OC-Supported-Features AVP and, if it does so, needs to make sure that 
doing so doesn't break anything.  The actual text will be better but 
this is the basic concept.
> Proposed text: Diameter agents that support DOIC SHOULD ensure that all request messages have the OC-Supported-Features AVP.
SRD> I disagree with the change.  Diameter agents can also become 
reporting node in the case that a server doesn't support DOIC.  In this 
case the agent will insert OC-Supported-Features in answer messages in 
the same way that a reporting node does.  The text needs to capture the 
point that the agent must not include the OC-Supported-Features AVP in 
answer messages for transactions where the request did not contain the 
OC-Supported-Features AVP.
> Proposed text: If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP.
SRD> I disagree with the change for the same reason as the previous comment.
> Proposed text: If the request message already has the OC-Supported-Features AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect the agent's set of support…
SRD> I disagree with the change.  See comment earlier based on 
discussions in the working group meeting.
> [LM] discussed in a separate mail.
SRD> See above.
> [LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS.
SRD> I'm ok with Ulrich's change.
> Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours) MUST NOT be used.
SRD> We agreed in the working group meeting that we will not have an 
upper limit, so the sentence with this bug will be removed from the 
document.

---

From: <[email-masked]>
Date: Fri, 14 Nov 2014 00:05:22 +0000

[LM] and this is incorrect but not fundamental. The reporting node does not have to "remember" a previously sent OLR. What it will do is to refer to existing OCS to know that throttling should not be applied. An OCS is a consequence of an sent OLR but it is not an OLR itself. But not fundamental here.

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : jeudi 13 novembre 2014 19:50
À : Wiehe, Ulrich (NSN - DE/Munich); MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [email-masked]
Objet : Re: [Dime] Updates to DOIC -05

Ulrich,

Please see inline.

Steve

On 11/12/14, 3:00 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Envoyé : mardi 11 novembre 2014 13:47 À : MORAND Lionel IMT/OLN; Maria 
> Cruz Bartolome; Steve Donovan; [email-masked] Objet : RE: [Dime] 
> Updates to DOIC -05
>
> Lionel,
> I am very sorry.
>
SRD> Agent overload isn't yet defined so we can't refer to it in this
document.  I also perfectly ok, in fact, it is expected behavior, for a reacting node for a host report to send realm routed requests to a different agent as the reacting node does not know which host will end up handling the request.
SRD> We discussed this is the working group meeting this week. The text
will be updated to indicate that agents can modify the OC-Supported-Features AVP and, if it does so, needs to make sure that doing so doesn't break anything.  The actual text will be better but this is the basic concept.
SRD> I disagree with the change.  Diameter agents can also become
reporting node in the case that a server doesn't support DOIC.  In this case the agent will insert OC-Supported-Features in answer messages in the same way that a reporting node does.  The text needs to capture the point that the agent must not include the OC-Supported-Features AVP in answer messages for transactions where the request did not contain the OC-Supported-Features AVP.
SRD> See above.
SRD> We agreed in the working group meeting that we will not have an
upper limit, so the sentence with this bug will be removed from the document.
> ______________________________________________________________________
> ___________________________________________________
>
> ______________________________________________________________________
> ___________________________________________________
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 14 Nov 2014 02:06:55 +0200

Inline..

11/13/2014 8:49 PM, Steve Donovan kirjoitti:
>> Some of my comments are immediate reactions to MCruz's comments. I do
>> not repeat those here (assuming that people who can read MCruz's
>> comments can also read my reaction, while people who cannot will not
>> be able to understand my reaction anyway as it would be out of context).
>> Existing text: For example, a single Diameter node may be overloaded,
>> in which case reacting nodes may reasonably attempt to send requests
>> to other destinations or via other agents.
>> Proposed text: For example, a single Diameter node may be overloaded,
>> in which case reacting nodes may reasonably attempt to send requests
>> to other destinations or - if agent overload control is supported
>> (Section A.2) - via other agents.
>>
>> [Ulrich] In the absence of agent overload control it is always the
>> server or realm that is overloaded and then it is not reasonable to
>> attempt sending requests via other agents to the same overloaded
>> server or realm.
>> For example, one or more Diameter agents that do not support DOIC may
>> exist between a given pair of reporting and reacting nodes, as long as
>> those agents pass unknown AVPs through unchanged.
>> Proposed text: For example, one or more Diameter agents that do or do
>> not support DOIC may exist between a given pair of reporting and
>> reacting nodes, as long as those agents pass OC-specific AVPs or
>> unknown AVPs through unchanged.
>>
>> [Ulrich] yes, but the exist text does not cover the case where a DOIC
>> supporting agent exists between a given pair of reporting and reacting
>> nodes, which passes OC-specific AVPs (although not unknown) through
>> unchanged.

[JiK] Agree with Steve here. And since an agent that may fiddle with 
non-routing AVPs is typically (or actually) a proxy, it can do whatever 
it see best as long as stuff does not break.

>> Existing text: This ensures that there is at least one commonly
>> supported overload abatement algorithm between the reporting node and
>> the reacting nodes in the path of the request.
>> Proposed text: This ensures that there is at least one commonly
>> supported overload abatement algorithm between the reporting node and
>> the reacting node in the path of the request.
>>

[JiK] ;-)

> SRD> This is addressed in a separate email.

[JiK] I see no reason to change the text. I do kind of agree what Ulrich 
says (in the separate mail), however, all those funny combinations are 
manageable by a proxy agent if it so wished (since it can manipulate 
more of less anything that goes through it). But still I see no reason 
to change the text.

>> Existing text: In this case, the agent updates the
>> OC-Supported-Feature AVP to reflect the mixture of the two sets of
>> supported features.
>> Proposed text: In this case, the agent can replace the
>> OC-Supported-Features AVP (which indicates the features supported by
>> the downstream reacting node) with its own OC-Supported-Feature AVP
>> (which indicates the features supported by the agent). By doing so,
>> the agent takes the role of a reporting node (reporting towards the
>> downstream reacting node) and at the same time takes the role of a
>> reacting node (reacting on OLRs received from upstream reporting nodes).
>>
>> Existing text: Diameter agents that support DOIC SHOULD ensure that
>> all messages have the OC-Supporting-Features AVP.
>> Proposed text: Diameter agents that support DOIC SHOULD ensure that
>> all request messages have the OC-Supported-Features AVP.
>>
>> [LM] ok

[JiK] Agree with Steve here.

>> Existing text: If a message handled by the DOIC agent does not include
>> the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP.
>> Proposed text: If a request message handled by the DOIC agent does not
>> include the OC-Supported-Features AVP then the DOIC agent SHOULD
>> insert the AVP.
>>
>> [LM] ok

[JiK] Agree with Steve here.

>> Existing text: If the message already has the OC-Supported-Features
>> AVP then the agent either leaves it unchanged in the relayed message
>> or modifies it to reflect a mixed set of DOIC features.
>> Proposed text: If the request message already has the
>> OC-Supported-Features AVP then the agent either leaves it unchanged in
>> the relayed message or modifies it to reflect the agent's set of
>> supported DOIC features.
>>
>> [LM] ok

[JiK] Agree with Steve again..

>> Proposed text: An agent MAY replace the OC-Supported-Features AVP
>> carried in answer messages (which indicates the features
>> supported/selected by the upstream reporting node) with its own
>> OC-Supported-Feature AVP (which indicates the features
>> supported/selected by the agent).
>>
>> Existing text: Therefore, the reporting node SHOULD NOT apply
>> throttling to the set of messages to which the OLR applies.
>> Proposed text: Therefore, the reporting node SHOULD NOT apply
>> throttling to the set of messages to which the sent OLR applies.
>>
>> [LM] I would say that the reporting node will not remember the
>> previously sent OLR, but will take care that there is an active OCS.
>> Section 6.5, 1st paragraph, 5th sentence Existing text: Validity
>> duration with values above 86400 (i.e.; 24 hours) MUST NOT be used.

- Jouni

>> Please stop commenting through attached documents, requested several
>> times and explained again yesterday by Ben. Some people may not be
>> able to read at all the attached documents and it makes impossible
>> parsing mechanism in the mailing list and in the archives.
>>
>> I have done another end-to-end read of the DOIC specification,
>> focusing on wording, consistency and removing any remaining redundancy
>> in the document.
>>
>> 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.
>>
>> privileged information that may be protected by law; they should not
>> be distributed, used or copied without authorisation.
>> 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.
>>
>> privileged information that may be protected by law; they should not
>> be distributed, used or copied without authorisation.
>> 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,
>> privileged information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 14 Nov 2014 01:36:30 +0000

Initially, I had the same issue with one or multiple reacting nodes.
But after further discussions and based on the example given below, I agree with Steve's proposal i.e. "reacting node(s)".

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : jeudi 13 novembre 2014 17:54
À : Wiehe, Ulrich (NSN - DE/Munich); MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [email-masked]
Objet : Re: [Dime] Updates to DOIC -05

Ulrich,

The basic scenario, when there are agents between Diameter Clients and Diameter Servers, for handling of host reports requires two separate Diameter nodes to act on the host report.

The client in your first case is responsible for applying abatement treatment to host routed requests.

The agent is responsible for applying abatement treatment to realm routed requests.

As such, there can be more than one reacting node for a single overload report.

Steve

On 11/12/14, 10:48 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> C is reacting node (reacting on host-type OLRs received from S), A (no 
> matter whether or not it supports DOIC) is neither reacting node nor 
> reporting node, S is reporting node C and S must have at least one 
> commonly supported algorithm.
>
> C is neither reacting node nor reporting node, A is reacting node (on 
> behalf of C), S is reporting node A and S must have at least one 
> commonly supported algorithm.
>
> C is reacting node (reacting on realm-type OLRs received from A), A is 
> reporting node (reporting realm-type OLRs to C) and reacting node 
> (reacting on host-type OLRs received from S) S is reporting node C and 
> A must have at least one commonly supported algorithm, and A and S must have at least one commonly supported algorithm. No need for C, A, and S to have at least one commonly supported algorithm.
>
> What we DO NOT have is:
> A is reacting node but not reporting node, S is reporting node If we 
> had this then yes There would be the need for C, A, and S to have at 
> least one commonly supported algorithm, and There would be the need to 
> modify the algorithm negotiation mechanism: e.g. when C supports loss, A supports loss and rate, S supports loss and rate, then A would not be allowed to advertize rate and loss to S but only loss.
>
> Ulrich
>
>
> I disagree with this change, as there can be more than one reacting 
> node for a single report.
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 17 Nov 2014 07:37:10 +0000

> document.  I also perfectly ok, in fact, it is expected behavior, for 
> a reacting node for a host report to send realm routed requests to a 

[MCruz] My proposal is to remove "or via other agents". Although it is true a request may use different intermediate agents, the reacting node does not choose that as per DOIC functionality. 
Then:

 Existing text: 
For example, a single Diameter node may be overloaded, 
in which case reacting nodes may reasonably attempt to send requests to other destinations or via other agents.

New text: 
For example, a single Diameter node may be overloaded, 
in which case reacting nodes may reasonably attempt to send requests to other destinations.

Best regards
/MCruz

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 17 Nov 2014 07:37:08 +0000

[MCruz] I am ok with Ulrich's change. It does not mean that the reporting node needs to "remember" a previously sent OLR, though. The change only proposes to "identify" which OLR we refer to.

Best regards
/MCruz

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 17 Nov 2014 07:39:45 +0000

>> exist between a given pair of reporting and reacting nodes, as long 
>> as those agents pass unknown AVPs through unchanged.
>> supporting agent exists between a given pair of reporting and 
>> reacting nodes, which passes OC-specific AVPs (although not unknown) 
>> through unchanged.
> SRD> I disagree with the change.  We have already identified cases 
> SRD> where

[JiK] Agree with Steve here. And since an agent that may fiddle with non-routing AVPs is typically (or actually) a proxy, it can do whatever it see best as long as stuff does not break.

I think we are losing a bit of context here.
Existing paragraph:

   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unchanged.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.

The example is trying to explain that DOIC works even if there are (DOIC or non-DOIC) agents between a reporting and a reacting node (i.e. they are  not "adjacent" nodes).
As it is now, a reader may wrongly infer than only non-DOIC agents may exist in between a reporting and reacting node. 
But in my opinion, the example should cover both cases.

Focusing just on the offending part, existing:
For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unchanged.  

Proposal:
For example, one or more
   Diameter agents, that may or not support DOIC, may exist between a given
   pair of reporting and reacting nodes. Non supporting DOIC agents passes
   unknown AVPs through unchanged.

---

From: <[email-masked]>
Date: Mon, 17 Nov 2014 08:34:59 +0000

If the proposal is accepted (I'm OK with), please remove "reasonably" :)

---- Maria Cruz Bartolome a écrit ----

 Existing text:

New text:

Best regards
/MCruz

---

From: <[email-masked]>
Date: Mon, 17 Nov 2014 08:38:24 +0000

I can live with the text proposed by Ulrich. But what is wrong with:

" Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which an active OCS applies." ?

---- Maria Cruz Bartolome a écrit ----

Best regards
/MCruz

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 17 Nov 2014 20:21:47 +0000

Hello,

"... to which an active OCS applies"
This shall refer to "active OCS" in the downstream node, since the OLR is sent downstream, and there it would (normally) turn into an active OCS.

Cheers
/MCruz

---- Maria Cruz Bartolome a écrit ----

Best regards
/MCruz

---

From: <[email-masked]>
Date: Mon, 17 Nov 2014 20:34:20 +0000

Correct! Sorry for being (too) slow! :)

-----Message d'origine-----
De : Maria Cruz Bartolome [mailto:[email-masked]] 
Envoyé : lundi 17 novembre 2014 21:22
À : MORAND Lionel IMT/OLN; Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Objet : RE: [Dime] Updates to DOIC -05

Hello,

Cheers
/MCruz

---- Maria Cruz Bartolome a écrit ----

Best regards
/MCruz

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Nov 2014 05:26:42 +0200

>     unknown AVPs through unchanged.

I think we cannot assure what the last sentence says. I would be ok if 
we change it to "..agents typically passes.."

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Nov 2014 10:12:39 -0600

Change made.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Nov 2014 10:13:38 -0600

Change made.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Nov 2014 10:19:00 -0600

inline...

> The example is trying to explain that DOIC works even if there are (DOIC or non-DOIC) agents between a reporting and a reacting node (i.e. they are  not "adjacent" nodes).
SRD> I disagree, this is trying to expain that DOIC works specifically 
when non-DOIC agents exist between reporting and reacting nodes.  Its 
saying that what we have defined in this document works in the presence 
of non supporting agents.
>     unknown AVPs through unchanged.
SRD> I don't see the need for this change.  Agents that support DOIC can 
also be reporting and reacting nodes.  This change implies this isn't 
the case.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Nov 2014 17:01:22 -0600

On reflection, I think there might be a subtlety here. The resulting offered-load may still exceed the reporting node's current capacity. This can be true even if it's sent an OLR (and thus has related OCS). As mentioned in the surrounding node needs to still be able to protect itself, possibly by throttling. Therefore, I propose the sentence take the form of non-normative guidance. For example:

"When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes.  If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes."

> On Nov 17, 2014, at 2:38 AM, [email-masked] wrote:
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Nov 2014 08:06:34 -0600

I'm ok with Ben's wording and will make the change unless I hear 
objections on the list.

Steve

---

From: <[email-masked]>
Date: Tue, 25 Nov 2014 18:26:07 +0000

I'm OK with the idea of the text proposed by Ben.
I would just make clear that throttling is applicable to the fact of sending/forwarding requests (cf. definition). A reporting node may apply local throttling if it is an agent. But if it is a server, it can either drop the exceeded number of requests (no response sent to the downstream) or send a specific DIAMETER-TOO-BUSY response. I think that this clarification is somehow missing in the document.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mardi 25 novembre 2014 15:07
À : Ben Campbell; MORAND Lionel IMT/OLN
Cc : Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; Maria Cruz Bartolome
Objet : Re: [Dime] Updates to DOIC -05

I'm ok with Ben's wording and will make the change unless I hear objections on the list.

Steve

On 11/21/14, 5:01 PM, Ben Campbell wrote:
>> _____________________________________________________________________
>> ____________________________________________________
>>