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

[Jouni Korhonen <[e-mail]>]

Some comments inline.

On Nov 5, 2013, at 3:29 AM, [e-mail] wrote:

> 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 J
> 
> Regards,
> 
> Lionel
> 
> De : [e-mail] [mailto:[e-mail]] De la part de Steve Donovan
> Envoyé : mardi 5 novembre 2013 00:54
> À : [e-mail]; [e-mail]
> 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
> 
>     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.


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


> 
>  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.

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.




> 
> 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.

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.

> 
> 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.
> 

Done.

> 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.

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.



> 
> 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. 

Right. Any conclusion here? 




> 
>  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.

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?



> 
> 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.

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.

> 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.

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

> 
>  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.

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..



> 
> 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.

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.


> 
> 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."


These are to be filled..


> 
> 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.
> 
> 
> 
> 


- JOuni


> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> doc-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doc-dt