Subject: [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt

From: Steve Donovan <[email-masked]>
Date: Mon, 04 Nov 2013 15:54:21 -0800

All,

I've included the DIME list on this email as the plan is to start 
migrating the Diameter Overload work from the design team to the DIME 
list now that the -01 version of the draft is out.

There are a number of open issues listed in the draft.  I have listed 
them here is some preliminary comments (preceded by srd>) on each.

Note that this is just addressing issues that are explicitly called out 
in the draft.  There are likely other issues that will be raised as the 
draft gets more review.

Regards,

Steve

----

Section 2

    Server Farm

       A set of Diameter servers that can handle any request for a given
       set of Diameter applications.  While these servers support the
       same set of applications, they do not necessarily all have the
       same capacity.  An individual server farm might also support a
       subset of the users for a Diameter Realm.

       [OpenIssue: Is a server farm assumed to support a single realm?
       That is, does it support a set of applications in a single realm?]

srd> Server farms are just groups of servers.  There is nothing to 
prevent a server from supporting multiple applications in multiple 
realms so the same should be the case for server farms.

    Server Front End

       A Server Front End (SFE) is a role that can be performed by a
       Diameter agent -- either a relay or a proxy -- that sits between
       Diameter clients and a Server Farm.  An SFE can perform various
       functions for the server farm it sits in front of.  This includes
       some or all of the following functions:

       *  Diameter Routing

       *  Diameter layer load balancing

       *  Load Management

       *  Overload Management

       *  Topology Hiding

       *  Server Farm Identity Management

       [OpenIssue: We used the concept of a server farm and SFE for
       internal discussions.  Do we still need those concepts to explain
       the mechanism?  It doesn't seem like we use them much.]

srd> We don't yet have the mechanism section written (section 5.5).  
This is where I would expect any wording dealing with server front ends 
that are doing overload management to end up.  The rest of the server 
front end language is context for that discussion.

Section 3.1.1

    Pseudo-session applications:  While this class of application does
       not use the Diameter Session-ID AVP to correlate requests, there
       is an implied ordering of transactions defined by the application.
       The 3GPP defined Cx application [reference] is an example of a
       pseudo-session application.

    [OpenIssue: Do we assume that all requests in a pseudo-session
    typically need to go to the same server?]

srd> The assumption is that the first request in a pseudo session is 
Destination-Realm routed and the answer message contains an 
Origin-Host.  The diameter id in received in the answer origin-host avp 
is then used as the destinition-host avp of subsequent requests.  That's 
a long way of saying yes.

Section 3.1.3

    Correlated Session-Initiating Request:  There are cases, most notably
       in the 3GPP PCC architecture, where multiple Diameter sessions are
       correlated and must be handled by the same Diameter server.  This
       is a special case of a Session-Initiating Request.  Gx CCR-I
       requests and Rx AAR messages are examples of correlated session-
       initiating requests.

       [OpenIssue: The previous paragraph needs references.]

srd> We should add a reverence to the PCC architecture spec.

Section 3.1.5

    o  Client --- Session Correlating Agent --- Multiple Equivalent
       Servers

    [OpenIssue: Do the "multiple equivalent servers" cases change for
    session-stateful applications?  Do we need to distinguish equivalence
    for session-initiation requests vs intra-session requests?]

srd> Given this is a PCC case, the only case where multiple equivalent 
servers could be used for routing a request is for the session that 
results in a binding.  All other requests, both new session requests 
routed based on the binding and intra-session requests are routed to a 
specific server.  A long was of saying no.

    o  DOC client --- agent --- Partitioned/Segmented DOC server

    o  DOC client --- agent --- agent --- Partitioned/Segmented DOC
       server

    o  DOC client --- edge agent --- edge agent --- DOC server

    [OpenIssue: In the last 3 list entries, are the agents DOC or non-
    DOC?]

srd> A change to this has been suggested in the past and just hasn't 
made it into the document yet.  We clearly need to include both DOC 
supporting agents and non DOC supporting agents.

Section 3.1.6

    o  This requirement also implies that if the Diameter agent does not
       impersonate the servers behind it, the Diameter dialogue is
       established between clients and servers and any overload
       information received by a client would be from a given server
       identified by the Origin-Host identity.

    [OpenIssue: We've discussed multiple situations where an agent might
    insert an OLR.  I don't think we mean to force them to always perform
    topology hiding or SFIM in order to do so.  We cannot assume that an
    OLR is always "from" or "about" the Origin-Host.  Also, the section
    seems to assume that topology hiding agents act as b2b overload
    agents, but non-topology hiding agents never do.  It don't think
    that's the right abstraction.  It's possible that topology-hiding
    agents must do this, but I don't think we can preclude non-topology
    hiding agents from also doing it, at least some of the time.]

srd> This is still an open issue on handling of "host" overload reports 
and "realm" overload reports.

    OC-OLR ::= < AVP Header: TBD2 >
               < TimeStamp >
               [ Reduction-Percentage ]
               [ ValidityDuration ]
               [ ReportType ]
             * [ AVP ]

    The TimeStamp AVP indicates when the original OC-OLR AVP with the
    current content was created.  It is possible to replay the same OC-
    OLR AVP multiple times between the overload endpoints, however, when
    the OC-OLR AVP content changes or the other information sending
    endpoint wants the receiving endpoint to update its overload control
    information, then the TimeStamp AVP MUST contain a new value.

    [OpenIssue: Is this necessarily a timestamp, or is it just a sequence
    number that can be implemented as a timestamp?  Is this timestamp
    used to calculate expiration time? (propose no.).  We should also
    consider whether either a timestamp or sequence number is needed for
    protection against replay attacks.]

srd> The primary reason for the timestamp is to distinguish when an 
overload report is new.   A sequence number would word just as well, as 
long as it is unique across space and time.  I agree that this should 
not be used by the reacting node to calculate expiration time.  The 
reacting node should use its own local time plus the duration value in 
the overload report.  We should choose either timestamp or sequence 
number and go forward with our choice.

Section 4.5

    The ReportType AVP is envisioned to be useful for situations where a
    reacting node needs to apply different overload treatments for
    different "types" of overload.  For example, the reacting node(s)
    might need to throttle requests that are targeted to a specific
    server by the presence of a Destination-Host AVP than for requests
    that can be handled by any server in a realm.  The example in
    Appendix C.3 illustrates this usage.

    [OpenIssue: There is an ongoing discussion about whether the
    ReportType AVP is the right way to solve that issue, and whether it's
    needed at all.]

srd> This is part of the earlier issue from section 3.1.6.  I propose we 
include the reporttype AVP and the report type explicit.

Section 4.6

    The value of the Reduction-Percentage AVP is between zero (0) and one
    hundred (100).  Values greater than 100 are interpreted as 100.  The
    value of 100 means that no traffic is expected, i.e. the sender of
    the information is under a severe load and ceases to process any new
    messages.  The value of 0 means that the sender of the information is
    in a stable state and has no requests to the other endpoint to apply
    any traffic abatement.

    [Open Issue: We should consider an algorithm independent way to end
    an overload condition.  Perhaps setting the validitytime to zero?
    Counter comment; since the abatement is based on a specific
    algorithm, it is natural to indicate that from the abatement
    algorithm point of view status quo has been reached.]

srd> I thought that we agreed to setting the validity duration to zero 
was the mechanism to indicate that the overload condition had ended in 
the reporting node.

    If an overload control endpoint comes out of the 100 percent traffic
    reduction as a result of the overload report timing out, the
    following concerns are RECOMMENDED to be applied.  The endpoint
    sending the traffic should be conservative and, for example, first
    send few "probe" messages to learn the overload condition of the
    other endpoint before converging to any traffic amount/rate decided
    by the sender.  Similar concerns actually apply in all cases when the
    overload report times out unless the previous overload report stated
    0 percent reduction.

    [Open Issue: It is still open whether we need an AVP to indicate the
    exact used traffic abatement algorithm.  Currently it assumed that
    the reacting node is able to figure out what to do based on the
    Reducttion-Percentage AVP and possible other embedded information
    inside the OC-OLR AVP.]

srd> There has been a lot of discussion on this.  The current proposal 
is for each defined algorithm to define its own set of AVPs to carry 
information needed by the reacting node.  This could be used to 
implicitly determine the algorithm to be used.  It is still an open 
issue whether the abatement algorithm that the server will request is 
communicated in the capabilities exchange.  My proposal is that the 
server does indicated the preferred algorithm as part of capabilities 
negotiation.

Section 5.3.1

    The basic principle is that the request message initiating endpoint
    (i.e. the "reacting node") announces its support for the overload
    control mechanism by including in the request message the OC-Feature-
    Vector AVP with those capability flag bits set that it supports and
    is willing to use for this Diameter session (or transaction in a case
    of a non-session state maintaining applications).  In a case of
    session maintaining applications the request message initiating
    endpoint does not need to do the capability announcement more than
    once for the lifetime of the Diameter session.  In a case of non-
    session maintaining applications, it is RECOMMENDED that the request
    message initiating endpoint includes the capability announcement into
    every request regardless it has had prior message exchanges with the
    give remote endpoint.

    [OpenIssue: We need to think about the lifetime of a capabilities
    declaration.  It's probably not the same as for a session.  We have
    had proposals that the feature vector needs to go into every request
    sent by an OC node.  For peer to peer cases, this can be associated
    with connection lifetime, but it's more complex for non-adjacent OC
    support.]

srd> I think the proposal is that capabilities advertised last either 
forever or until the a changed OC-Feature-Vector AVP is sent, which ever 
comes first.

Section 5.5.2

    [OpenIssue: did we now agree that e.g. a server can refrain sending
    OLR in answers based on some magical algorithm?  (Note: We seem to
    have consensus that a server MAY repeat OLRs in subsequent messages,
    but is not required to do so, based on local policy.)]

srd> We need to have wording to capture the behavior.  I think wording 
something like "the reporting node should send overload reports in all 
answer messages.  The reporting node can choose to not include the 
overload report in answers if it has the ability to determine that the 
reacting node that will receive the answer message has already received 
the overload report.  Note that determining which reacting nodes have 
received the overload report is difficult in deployments that include 
agents."

Section 8

    The lack of end-to-end security features makes it far more difficult
    to establish trust in overload reports that originate from non-
    adjacent nodes.  Any agents in the message path may insert or modify
    overload reports.  Nodes must trust that their adjacent peers perform
    proper checks on overload reports from their peers, and so on,
    creating a transitive-trust requirement extending for potentially
    long chains of nodes.  Network operators must determine if this
    transitive trust requirement is acceptable for their deployments.
    Nodes supporting Diameter overload control MUST give operators the
    ability to select which peers are trusted to deliver overload
    reports, and whether they are trusted to forward overload reports
    from non-adjacent nodes.

    [OpenIssue: This requires that a responding node be able to tell a
    peer-generated OLR from one generated by a non-adjacent node.  One
    way of doing this would be to include the identity of the node that
    generated the report as part of the OLR]

srd> We currently do not include the identity of the responding node in 
the overload report.  It is highly likely that it will be required as 
part of the end-to-end security solution that is currently being 
worked.  I propose that we include the identity in the overload report 
based on this expectation.

    [OpenIssue: Do we need further language about what rules an agent
    should apply before forwarding an OLR?]

srd> I think we should but we don't yet have section 5.5 written and 
this is likely where this will go.

       The lack of end-to-end protection creates a tension between two
       requirements from the overload control requirements document.
       [I-D.ietf-dime-overload-reqs] Requirement 34 requires the ability
       to send overload reports across intermediaries (i.e. agents) that
       do not support overload control mechanism.  Requirement 27 forbids
       the mechanism from adding new vulnerabilities or increasing the
       severity of existing ones.  A non-supporting agent will most
       likely forward overload reports without inspecting them or
       applying any sort of validation or authorization.  This makes the
       transitive trust issue considerably more of a problem.  Without
       the ability to authenticate and integrity protect overload reports
       across a non-supporting agent, the mechanism cannot comply with
       both requirements.

       [OpenIssue: What do we want to do about this?  Req27 is a
       normative MUST, while Req34 is "merely" a SHOULD.  This would seem
       to imply that 27 has to take precedent.  Can we say that overload
       reports MUST NOT be sent to and/or accepted from non-supporting
       agents until such time we can use end-to-end security?]

srd> This needs to be discussed.

---

From: <[email-masked]>
Date: Tue, 5 Nov 2013 01:29:23 +0000

Hi Steve,

Thank you for initiating the discussion on the open issues.

>From a practical point of view, I recommend to have one thread per comment and to numerate the open issues. Otherwise it will become difficult manage all the answers and to follow the discussion if there are comments on different parts of this long mail.

It would even be an excellent opportunity to use the issue tracker tool :)

Regards,

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 5 novembre 2013 00:54
À : [email-masked]; [email-masked]
Objet : [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt

All,

I've included the DIME list on this email as the plan is to start migrating the Diameter Overload work from the design team to the DIME list now that the -01 version of the draft is out.

There are a number of open issues listed in the draft.  I have listed them here is some preliminary comments (preceded by srd>) on each.

Note that this is just addressing issues that are explicitly called out in the draft.  There are likely other issues that will be raised as the draft gets more review.

Regards,

Steve

----

Section 2

   Server Farm

      That is, does it support a set of applications in a single realm?]
srd> Server farms are just groups of servers.  There is nothing to prevent a server from supporting multiple applications in multiple realms so the same should be the case for server farms.

   Server Front End

      *  Diameter Routing

      *  Load Management

      *  Overload Management

      *  Topology Hiding

      the mechanism?  It doesn't seem like we use them much.]
srd> We don't yet have the mechanism section written (section 5.5).  This is where I would expect any wording dealing with server front ends that are doing overload management to end up.  The rest of the server front end language is context for that discussion.

Section 3.1.1

   typically need to go to the same server?]
srd> The assumption is that the first request in a pseudo session is Destination-Realm routed and the answer message contains an Origin-Host.  The diameter id in received in the answer origin-host avp is then used as the destinition-host avp of subsequent requests.  That's a long way of saying yes.

Section 3.1.3

      initiating requests.

Section 3.1.5

      Servers

   for session-initiation requests vs intra-session requests?]
srd> Given this is a PCC case, the only case where multiple equivalent servers could be used for routing a request is for the session that results in a binding.  All other requests, both new session requests routed based on the binding and intra-session requests are routed to a specific server.  A long was of saying no.

      server

   DOC?]
srd> A change to this has been suggested in the past and just hasn't made it into the document yet.  We clearly need to include both DOC supporting agents and non DOC supporting agents.

Section 3.1.6

   hiding agents from also doing it, at least some of the time.]
srd> This is still an open issue on handling of "host" overload reports and "realm" overload reports.

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

            * [ AVP ]

   protection against replay attacks.]
srd> The primary reason for the timestamp is to distinguish when an overload report is new.   A sequence number would word just as well, as long as it is unique across space and time.  I agree that this should not be used by the reacting node to calculate expiration time.  The reacting node should use its own local time plus the duration value in the overload report.  We should choose either timestamp or sequence number and go forward with our choice.

Section 4.5

   needed at all.]
srd> This is part of the earlier issue from section 3.1.6.  I propose we include the reporttype AVP and the report type explicit.

Section 4.6

   any traffic abatement.

   algorithm point of view status quo has been reached.]
srd> I thought that we agreed to setting the validity duration to zero was the mechanism to indicate that the overload condition had ended in the reporting node.

   0 percent reduction.

   inside the OC-OLR AVP.]
srd> There has been a lot of discussion on this.  The current proposal is for each defined algorithm to define its own set of AVPs to carry information needed by the reacting node.  This could be used to implicitly determine the algorithm to be used.  It is still an open issue whether the abatement algorithm that the server will request is communicated in the capabilities exchange.  My proposal is that the server does indicated the preferred algorithm as part of capabilities negotiation.

Section 5.3.1

   give remote endpoint.

   support.]
srd> I think the proposal is that capabilities advertised last either forever or until the a changed OC-Feature-Vector AVP is sent, which ever comes first.

Section 5.5.2

   but is not required to do so, based on local policy.)]
srd> We need to have wording to capture the behavior.  I think wording something like "the reporting node should send overload reports in all answer messages.  The reporting node can choose to not include the overload report in answers if it has the ability to determine that the reacting node that will receive the answer message has already received the overload report.  Note that determining which reacting nodes have received the overload report is difficult in deployments that include agents."

Section 8

   from non-adjacent nodes.

   generated the report as part of the OLR]
srd> We currently do not include the identity of the responding node in the overload report.  It is highly likely that it will be required as part of the end-to-end security solution that is currently being worked.  I propose that we include the identity in the overload report based on this expectation.

   should apply before forwarding an OLR?]
srd> I think we should but we don't yet have section 5.5 written and this is likely where this will go.

      both requirements.

_________________________________________________________________________________________________________________________

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, 5 Nov 2013 01:34:07 +0000

Useful link for new tickets: http://tools.ietf.org/wg/dime/trac/newticket

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 5 novembre 2013 02:29
À : Steve Donovan; [email-masked]; [email-masked]
Objet : Re: [doc-dt] [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt

Hi Steve,

Regards,

Lionel

All,

Regards,

Steve

----

Section 2

   Server Farm

   Server Front End

      *  Diameter Routing

      *  Load Management

      *  Overload Management

      *  Topology Hiding

Section 3.1.1

Section 3.1.3

      initiating requests.

Section 3.1.5

      Servers

      server

   DOC?]

Section 3.1.6

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

            * [ AVP ]

Section 4.5

   needed at all.]

Section 4.6

   any traffic abatement.

   0 percent reduction.

   inside the OC-OLR AVP.]

Section 5.3.1

   give remote endpoint.

   support.]

Section 5.5.2

Section 8

   from non-adjacent nodes.

      both requirements.

Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 27 Nov 2013 16:37:12 +0200

Some comments inline.

On Nov 5, 2013, at 3:29 AM, [email-masked] wrote:

> It would even be an excellent opportunity to use the issue tracker tool J
> 
> Regards,
> 
> Lionel
> 

I added text saying that a server farm may host a single or more realms.

> srd> We don't yet have the mechanism section written (section 5.5).  This is where I would expect any wording dealing with server front ends that are doing overload management to end up.  The rest…

Actually a server front end could be something that cannot be found from Diameter specs at all. It could also be a proprietary style request dispatcher in front of a pool of server service blades in a rack. Anyway, I do not want to go further in that discussion but such front ends exist.

> srd> The assumption is that the first request in a pseudo session is Destination-Realm routed and the answer message contains an Origin-Host.  The diameter id in received in the answer origin-host…

So what we want to do with this "open issue"? I would be tempted to leave the current text as it is.. if someone is more interested in pseudo-session applications, they can look up the reference.

> srd> We should add a reverence to the PCC architecture spec.

Done.

> srd> A change to this has been suggested in the past and just hasn't made it into the document yet.  We clearly need to include both DOC supporting agents and non DOC supporting agents.

Actually, I would be ready to drop Section 3.1.5 entirely. We have multiple deployment and architecture figures & considerations later in the document. That should suffice.

> srd> This is still an open issue on handling of "host" overload reports and "realm" overload reports. 

Right. Any conclusion here? 

> srd> The primary reason for the timestamp is to distinguish when an overload report is new.   A sequence number would word just as well, as long as it is unique across space and time.  I agree that…

I have now written text based on the sequence number. However, that generated another issue. With time stamps there was a documented way to handle an overflow of the time (as per NTP specs). Now with sequence numbers we need to define our own way of doing the overflow handling. That would be simple if we assume that people use the sequence number as a sequence number and do not e.g. just copy NTP 64 bit time into the value.. comments?

> srd> This is part of the earlier issue from section 3.1.6.  I propose we include the reporttype AVP and the report type explicit.

SLightly on the same opinion. However, we then need to do the required other clarifications regarding multiple OLRs etc. And I do not see a full agreement on that area yet.

> srd> I thought that we agreed to setting the validity duration to zero was the mechanism to indicate that the overload condition had ended in the reporting node.

This is my understanding as well. I did already remove the note from the text.

> srd> There has been a lot of discussion on this.  The current proposal is for each defined algorithm to define its own set of AVPs to carry information needed by the reacting node.  This could be u…

The current text in the -01 says that the server announces as many algorithms as it sees beneficial and at least one of them must overlap with a client announcement. This is not exactly picking up one algorithm but honestly I am giving up here. I am really confused about the route the capability announcement took at the end..

> srd> I think the proposal is that capabilities advertised last either forever or until the a changed OC-Feature-Vector AVP is sent, which ever comes first.

I wrote into -01 that capability announcement is recommended to be included every time. If I recall correctly there was the case where a request takes an alternative route (due something happening in the network -> rerouting) and for that case having capability announcement in every message is OKish.

> srd> We need to have wording to capture the behavior.  I think wording something like "the reporting node should send overload reports in all answer messages.  The reporting node can choose to not…

These are to be filled..

> srd> This needs to be discussed.

- JOuni

> _______________________________________________
> doc-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doc-dt