[Dime] Proposed Example Text for draft-docdt-dime-ovli-01

Ben Campbell <ben@nostrum.com> Tue, 05 November 2013 00:36 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6AB21E8396 for <dime@ietfa.amsl.com>; Mon, 4 Nov 2013 16:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level:
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd2cyWBpMw5e for <dime@ietfa.amsl.com>; Mon, 4 Nov 2013 16:36:44 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 28FD821E818C for <dime@ietf.org>; Mon, 4 Nov 2013 16:36:44 -0800 (PST)
Received: from dhcp-bc5b.meeting.ietf.org (dhcp-bc5b.meeting.ietf.org [31.133.188.91]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA50af13090748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dime@ietf.org>; Mon, 4 Nov 2013 18:36:43 -0600 (CST) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ABC222C8-466D-4672-9504-F881FED7CBEA"
Message-Id: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com>
Date: Mon, 04 Nov 2013 16:36:41 -0800
To: "dime@ietf.org list" <dime@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
X-Mailer: Apple Mail (2.1816)
Received-SPF: pass (shaman.nostrum.com: 31.133.188.91 is authenticated by a trusted mechanism)
Subject: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 00:36:46 -0000

Hi,

draft-docdt-dime-ovli-01 has a TBD item in appendix C, section 3. Namely,  an example showing a mix of Destination-Realm and Destination-Host routed requests. Here's a straw man proposal for that example. I don't expect this to be the "one true way" to approach the scenario; rather, it's a possible way to do it, and there are likely other ways as well.

Comments solicited.

Thanks!

Ben.

----------------------------

C.3.  Mix of Destination-Realm routed requests and Destination-Host
      reouted requests

   Diameter allows a client to optionally select the destination server
   of a request, even if there are agents between the client and the
   server.  The client does this using the Destination-Host AVP.  In
   cases where the client does not care if a specific server receives
   the request, it can omit Destination-Host and route the request using
   the Destination-Realm and ApplicationId AVPs, effectively letting an
   agent select the server.

   Clients commonly send mixtures of Destination-Host and Destination-
   Realm routed requests.  For example, in an application that uses user
   sessions, a client typically won't care which server handles a
   session-initiating requests.  But once the session is initiated, the
   client will send all subsequent requests in that session to the same
   server.  Therefore it would send the initial request with no
   Destination-Host AVP.  If it receives a successful answer, the client
   would copy the Origin-Host value from the answer message into a
   Destination-Host AVP in each subsequent request in the session.

   An agent has very limited options in applying overload abatement to
   requests that contain Destination-Host AVPs.  It typically cannot
   route the request to a different server than the one identified in
   Destination-Host.  It's only remaining options are to throttle such
   requests locally, or to send an overload report back towards the
   client so the client can throttle the requests.  The second choice is
   usually more efficient, since it prevents any throttled requests from
   being sent in the first place, and removes the agent's need to send
   errors back to the client for each dropped request.

   On the other hand, an agent has much more leeway to apply overload
   abatement for requests that do not contain Destination-Host AVPs.  If
   the agent has multiple servers in its peer table for the given realm
   and application, it can route such requests to other, less overloaded
   servers.

   If the overload severity increases, the agent may reach a point where
   there is not sufficient capacity across all servers to handle even



Korhonen, et al.          Expires May 03, 2014                 [Page 35]
Internet-Draft                    DOIC                      October 2013


   realm-routed requests.  In this case, the realm itself can be
   considered overloaded.  The agent may need the client to throttle
   realm-routed requests in addition to Destination-Host routed
   requests.  The overload severity may be different for each server,
   and the severity for the realm at is likely to be different than for
   any specific server.  Therefore, an agent may need to forward, or
   originate, multiple overload reports with differing ReportType and
   Reduction-Percentage values.

   Figure 8 illustrates such a mixed-routing scenario.  In this example,
   the servers S1, S2, and S3 handle requests for the realm "realm".
   Any of the three can handle requests that are not part of a user
   session (i.e. routed by Destination-Realm).  But once a session is
   established, all requests in that session must go to the same server.

                  Client     Agent      S1        S2        S3
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |(1) Request (DR:realm)       |         |
                     |-------->|         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |Agent selects S1   |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |(2) Request (DR:realm)       |
                     |         |-------->|         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |S1 overloaded, returns OLR
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |(3) Answer (OR:realm,OH:S1,OLR:RT=DH)
                     |         |<--------|         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |sees OLR,routes DR traffic to S2&S3
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |(4) Answer (OR:realm,OH:S1, OLR:RT=DH) |
                     |<--------|         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |Client throttles requests with DH:S1   |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |(5) Request (DR:realm)       |         |
                     |-------->|         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |Agent selects S2   |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |(6) Request (DR:realm)       |
                     |         |------------------>|         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |S2 is overloaded...
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |(7) Answer (OH:S2, OLR:RT=DH)|
                     |         |<------------------|         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |Agent sees OLR, realm now overloaded
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |(8) Answer (OR:realm,OH:S2, OLR:RT=DH, OLR: RT=R)
                     |<--------|         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |Client throttles DH:S1, DH:S2, and DR:realm
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |
                     |         |         |         |         |


      Figure 8: Mix of Destination-Host and Destination-Realm Routed
                                 Requests

   1: The client sends a request with no Destination-Host AVP (that is,
      a Destination-Realm routed request.)

   2: The agent follows local policy to select a server from its peer
      table.  In this case, the agent selects S2 and forwards the
      request.

   3: S1 is overloaded.  It sends a answer indicating success, but also
      includes an overload report.  Since the overload report only
      applies to S1, the ReportType is "Destination-Host".

   4: The agent sees the overload report, and records that S1 is
      overloaded by the value in the Reduction-Percentage AVP.  It
      begins diverting the indicated percentage of realm-routed traffic
      from S1 to S2 and S3.  Since it can't divert Destination-Host
      routed traffic, it forwards the overload report to the client.
      This effectively delegates the throttling of traffic with
      Destination-Host:S1 to the client.

   5: The client sends another Destination-Realm routed request.

   6: The agent selects S2, and forwards the request.

   7: It turns out that S2 is also overloaded, perhaps due to all that
      traffic it took over for S1.  S2 returns an successful answer
      containing an overload report.  Since this report only applies to
      S2, the ReportType is "Destination-Host".

   8: The agent sees that S2 is also overloaded by the value in
      Reduction-Percentage.  This value is probably different than the
      value from S1's report.  The agent diverts the remaining traffic
      to S3 as best as it can, but it calculates that the remaining
      capacity across all three servers is no longer sufficient to
      handle all of the realm-routed traffic.  This means the realm
      itself is overloaded.  The realm's overload percentage is most
      likely different than that for either S1 or S2.  The agent
      forward's S2's report back to the client in the Diameter answer.
      Additionally, the agent generates a new report for the realm of
      "realm", and inserts that report into the answer.  The client
      throttles requests with Destination-Host:S1 at one rate, requests
      with Destination-Host:S2 at another rate, and requests with no
      Destination-Host AVP at yet a third rate.  (Since S3 has not
      indicated overload, the client does not throttle requests with
      Destination-Host:S3.)