Re: [Dime] DOIC Endpoint behavior -- Capability Exchange

[Maria Cruz Bartolome <[e-mail]>]

Hello Ulrich et all,

As far as I can follow your comments on diagram, I tend to agree with your proposal, but I cannot fully follow this, since diagram is not properly received.
Is it possible to provide diagram in another format that is not modified by each one email configuration? I think this is very important for discussion and agreement
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 04 de febrero de 2014 14:44
To: ext Steve Donovan; [e-mail]
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange

Steve,

please find comments inline.

Regards
Ulrich

From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 04, 2014 12:55 AM
To: [e-mail]
Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange

All,

I believe that the current DOIC Endpoint behavior definition is not sufficiently defined, especially for agents.
<Ulrich> I agree. </Ulrich>

There was also a change introduced in the -01 version of the draft that implies that there can be a DOIC association that goes through a DOIC enabled agent.  This was not  how I understood endpoints.
<Ulrich> same with me </Ulrich>  The original diagrams showed a DOIC agent as terminating an endpoint that came to it.    I suspect there were different assumptions that lead to clearly different interpretations.  

I propose that we return to the original diagrams and add the wording below on how DOC agents behave.  One way to look at this is that DOC agents act as back-to-back DOC endpoints.  I intentionally don't say back-to-back Diameter endpoints because this does not impact anything except the handling of DOIC related AVPs.

Note that I don't believe this requires any changes to Diameter clients or servers.  I also don't believe this requires any changes to the contents of the DOIC related AVPs but there is an open question as to whether there is a need to indicate when a OC-Supported-Features AVP is generated or modified by an agent.

I propose to add the following section to the section on capabilities announcement.  I'll send a separate email proposing text to section 5.5 on how DOC agents are to behave. 

Regards,

Steve

-----

5.3.1 DOC Agent handling of DOIC capability exchange.

A DOC agent is defined as a Diameter agent that supports the DOIC extension.
<Ulrich> A Diameter agent that supports the DOIC extension is not necessarily taking the role of a reacting DOIC endpoint.
It only takes the role of a reacting DOIC endpoint when receiving a request that does not contain an OC-Supported-Features AVP.
Similarily a Diameter agent that supports the DOIC extensions is not necessarily taking the role of a reporting DOIC endpoint.
It only takes the role of a reporting DOIC endpoint when receiving a realm type request (not containing a destination host) that contains an OC-Supported-Features AVP while it is configured to act as a reporting DOIC endpoint for that realm. </Ulrich>

A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension <Ulrich> and decided to take the role of a reacting DOIC endpoint and/or reporting DOIC endpoint </Ulrich>.

An downstream DOIC Association is defined as the association between the DOIC supporting Diameter entity that sends a Diameter request message to a DOC agent and the DOC agent.

A upstream DOIC Association is defined as the association between a DOC agent and the Diameter entity to which the DOC agent sends the Diameter request message.  The following illustrated the upstream and downstream concepts.

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node
  Direction of request message for a transaction ----->
  Direction of answer message for a transaction <----- <Ulrich> this depends on the point of view: one node's downstream DOIC association is another node's upstream DOIC association. </Ulrich> <Ulrich> The general case is:

+---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
| client  |      | A1      |     | A2     |     | A3     |                          | A4     |                | server |
| no DOIC |      | no DOIC |     | DOIC   |     | DOIC   |                          | DOIC   |                | DOIC   |
| support |      | support |     | support|     | support|                          | support|                | support| 
+---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
    |                 |              |              |                                 |                             |
    |                 |              |<---DOIC association 1------------------------->|<-------DOIC association 2-->|
    |                 |              |              |                                 |                             |
    |                 |              |<-----------------DOIC association 3----------------------------------------->|
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |----1.xxR------->|---2.xxR----->|              |                                 |                             |
    |                 |              |---3.xxR----->|----4.xxR----------------------->|                             |
    |                 |              |              |                                 |--------5.xxR--------------->| 
    |                 |              |              |                                 |<-------6.xxA----------------|
    |                 |              |<--8.xxA------|<---7.xxA------------------------|                             |
    |<---10.xxA-------|<--9.xxA------|              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |----11.xxR------>|---12.xxR---->|              |                                 |                             |
    |                 |              |---13.xxR---->|-----14.xxR--------------------->|-------15.xxR--------------->|
    |                 |              |              |                                 |                             |
    |                 |              |<---18.xxA----|<----17.xxA----------------------|<-----16.xxA-----------------|
    |<---20.xxA-------|<---19.xxA----|              |                                 |                             |
    |                 |              |              |                                 |                             |
DOIC association 1 is for realm type requests; DOIC association 2 is for request for which A4 selects the server DOIC association 3 is for host type requests

1. the client that does not support DOIC sends 1.xxR (realm type request not containing destination host) to the next hop; 1.xxR does not contain an OC-Supported-Features AVP 2. the agent A1 that does not support DOIC forwards the request to the next hop; 2.xxR still dos not contain an OC-Supported-Feature AVP.
3. the agent A2 that supports DOIC decides to take the role of a reacting endpoint; it inserts an OC-Supported-Features AVP into 3.xxR indicating support of features 1 and 2 (in this example).
4. agent A3, although it supports DOIC, does not take the role of a reacting endpoint (because 3.xxR contains an OC-Supported-Features AVP); it also does not take the role of a reporting endpoint since it is not configured to act as reporting endpoint for the destination realm received in 3.xxR; 4.xxR (unmodified) is sent to the next hop.
5. agent A4 is configured to take the role of the reporting endpoint for the realm. It therefore removes the OC-Supported-Features AVP reveived in 4.xxR and inserts its own supported features (in this example features 1 and 3) in 5.xxR. A4 also selects the server to which 5.xxR is sent.
6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA including an OLR1 (host type) requesting a feature 3 specific traffic reduction (e.g. window size 20). 
7. A4 calculates the overall realm overload level, removes the received OLR1 and adds its own calculated realm type OLR2 (e.g. a feature 1 specific traffic reduction of 50%-loss) to 7.xxA. A4 stores OLR1 for later use.
8. A3 not taking any DOIC role forwards the answer unmodified.
9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores OLR2 for later use.
10. A1 not supporting DOIC is transparent.
11. client sends a new request 11.xxR (containing destination host as learnd from 10.xxA; no OC-Supported-Features AVP included.
12. A1 is transparent.
13. A2 decides to take the role of the reacting endpoint and includes again its supported features 1 and 2 in OC-Supported-Features AVO sent within 13.xxR.
14. A3 is transparent
15. A4 is transparent for host type requests that contain an OC-Supported-Features AVP.
16. server returns 16.xxA including a host type OLR3 requesting a feature 1 specific traffic reduction of e.g. 30%-loss.
17. A4 is transparent
18. A3 is transparent
19. A2 stores OLR3 for later use and may remove OLR3 when sending 19.xxA.
20. client receives 20.xxA.
</Ulrich>

Four scenarios must be supported:

  - Scenario 1 - There is both an upstream and downstream DOIC association.
<Ulrich> for example see A4 in the figure above </Ulrich>
  - Scenario 2 - There is no upstream DOIC association <Ulrich> do you mean "There is a downstream DOIC association but no upstream DOIC association"? Not covered in the figure above. </Ulrich>
  - Scenario 3 - There is no downstream DOIC association <Ulrich> do you mean "There is an upstream DOIC association but no downstream DOIC association"? for example see A2 in the figure above </Ulrich>
  - Scenario 4 - No DOIC association in either direction <Ulrich> for example see A3 in the figure above </Ulrich>

Scenario 1 - Both upstream and downstream DOIC associations

Request message handling:

A DOC agent that receives a request that contains the OC-Supported-Features AVP must act as an endpoint for the downstream DOIC association.
<Ulrich> NO! see A3 receiving 3.xxR or 13.xxR (this may not be scenario 1, but how does the agent know which scenario applies?)</Ulrich>

If the DOC agent relays or proxies the request message then the agent must include an OC-Supported-Features AVP in the relayed message.  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.
<Ulrich>There cannot be more than one OC-Supported-Features AVPs in one request. An agent that inserts an OC-Supported-Features AVP must remove the received OC-Supported-Features AVP (see A4 when sending 5.xxR). The inserted OC-Supported Features AVP shall indicate the features the inserting node supports, not more, not less</Ulrich>

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent must modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported-Features AVP must be included in the relayed request message.

  Note: any DOIC extension must define the changes needed to the OC-Feature-Vector AVP and any additional AVPs that need to be added to the OC-Supported-Features AVP as part of the capabilities advertisement for that feature.

Question: Should there be an indication that the contents of the OC-Supported-Features AVP was changed?
<Ulrich> no. for what reason? </Ulrich>

Question: Will this work when end-to-end security is introduced?  Would adding a separate OC-Supported-Features AVP be better, especially when end-to-end security is considered?
<Ulrich> what is the issue? </Ulrich>

Answer message handling:

When an agent receives the  answer message that corresponds to the above request message <Ulrich> i.e. the request message into which the agent has inserted its OC-Supported-Features AVP </Ulrich> , the agent must act as the DOIC endpoint for the upstream DOIC association.  

If the DOC agent relays or proxies the answer message then the agent must include an OC-Supported-Features AVP in the relayed message.
<Ulrich> OC-Supported-Features AVP in answer messages is an open issue </Ulrich>
  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent should modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported Features AVP must be included in the relayed answer message.

Scenario 2 - No downstream DOIC association with an upstream association <Ulrich> wasn't that scenario 3? </Ulrich>

In this case a request is received that does not contain an OC-Supported-Features AVP.

Request message handling:

If a DOC agent receives a request that does NOT contain an OC-Supported-Features AVP then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The new OC-Supported-Features AVP must be included in the relayed/proxied request message.

The agent will then become the reacting DOIC endpoint for the upstream DOIC association that results from the transaction.  

Note: Section x.x.x defines agent behavior when it is the reacting node for a DOIC association.

Answer message handling

In this case the answer message will contain an OC-Supported-Features AVP.  The DOC agent must store the advertised capabilities for use when the DOC agent reacts to an overload report from the upstream Diameter node.

The DOC agent should remove the OC-Supported-Features AVP from the answer message before relaying/proxying the answer message.  

Scenario 3 - Downstream DOC association with no upstream DOIC association <Ulrich> wasn't this scenario 2? </Ulrich>

In this case a OC-Supported-Features AVP is received in the request from the downstream Diameter entity but no OC-Supported-Features AVP is received in the answer message received from the upstream Diameter entity.  In this case the agent must act as the reporting DOIC endpoint for the downstream DOIC association.
<Ulrich> this is totally new to me. Where does this come from? If a server does not support DOIC it cannot request load reduction from a downstream agent. The downstream agent (even if it would detect the DOIC-non-support of the server) cannot request load reduction from further downstream nodes on behalf of the server </Ulrich>

Request message handling:

Request message handling is the same as for scenario 1.

Answer message handling:

If a DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that includes an upstream DOC association then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The generation of this OC-Supported-Features AVP must also follow the rules specified in section 5.3.2.  The new OC-Supported-Features AVP must be included in the relayed/proxied the answer message.

Scenario 4 - No upstream association and no downstream association

Request message handling:

The request message handling in this case is the same as scenario 2.

Answer message handling:

If the DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that does not include a downstream DOC association then the agent must NOT generate an OC-Supported-Features AVP.  The DOC Agent must relay/proxy the answer message with no DOIC related change.

<Ulrich> the open issue seems to be: How can an agent determine which scenario is applicable? Let me try:
An agent that does not support DOIC is always in scenario 4 (no upstream DOIC association, no downstream DOIC association).
For an agent that supports DOIC:
When receiving a request that does not contain an OC-Supported-Features AVP the agent is in scenario 3 or 4 (no downstream DOIC association). Whether its 3 or 4 depends on whether or not an OLR is received in the corresponding answer.
When receiving a host type request (a request that contains a Destination-Host AVP) that contains an OC-Supported-Feature AVP the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association) When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured to act as reporting node for that realm, the agent is scenario 1 or 2 (there is a downstream DOIC association). Whether its 1 or 2 depends on whether or not an OLR is received in the corresponding answer.
When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured not to act as reporting node for that realm, the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association). </Ulrich>





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