Subject: [Dime] Diameter Overload - Destination-Host Scope

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 14 Jul 2013 12:54:25 +0000

Ben,

Can you describe scenarios where Destination-Host Scope would be used?

Thanks,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Labs
[email-masked]<mailto:[email-masked]>
+1-609-903-3360

---

From: Eric McMurry <[email-masked]>
Date: Sun, 14 Jul 2013 09:41:04 -0500

Hi Martin,

I think this could be one of the most used scopes.  Any time you want to throttle traffic towards a single server, or a cluster masquerading as a single server, this would be the go to scope.

For example, consider an MME  (mobility management) sending traffic to a cluster of HSSs (subscriber DBs) where the topology of the HSS cluster is not hidden.  Let's also assume that the HSSs in the cluster are responsible for different subscribers, and so may go into overload independently.  If one of these HSSs goes into overload, it could then use the destination-host scope towards the MME to request that MME to reduce traffic that it sends to just that HSS.  Traffic towards other HSSs would not be affected.

Does that make sense?

Thanks,

Eric

On Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C" <[email-masked]> wrote:

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

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 14 Jul 2013 14:52:35 +0000

Eric,

Does this assume that the server needs to have knowledge of the topology to which it is deployed in order to determine which Scope to send?

Thanks,

Martin

From: Eric McMurry [mailto:[email-masked]]
Sent: Sunday, July 14, 2013 10:41 AM
To: DOLLY, MARTIN C
Cc: [email-masked]; Ben Campbell ([email-masked])
Subject: Re: [Dime] Diameter Overload - Destination-Host Scope

Hi Martin,

Does that make sense?

Thanks,

Eric

On Jul 14, 2013, at 7:54 , "DOLLY, MARTIN C" <[email-masked]<mailto:[email-masked]>> wrote:

Ben,

Thanks,

Martin Dolly

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

---

From: Eric McMurry <[email-masked]>
Date: Sun, 14 Jul 2013 10:19:29 -0500

Hi Martin,

I think servers will likely be provisioned with knowledge of what scopes they can be authoritative for, and they need access to information for those scopes.  It comes down to whoever sends control information for a scope needs to know enough to report for that scope.

So for this example, the HSSs would need to know that they are authoritative for their hostname and that it is not being shared with other servers.  They shouldn't need to know anything else about the topology to use the destination-host scope.

Thanks,

Eric

---

From: Ben Campbell <[email-masked]>
Date: Sun, 14 Jul 2013 13:04:57 -0500

> So for this example, the HSSs would need to know that they are authoritative for their hostname and that it is not being shared with other servers.  They shouldn't need to know anything else about…

It's also possible that for the HSS to not be a scope authority for Destination-Host. It could simply use a Connection scoped report to an agent, and that agent could send another report downstream that indicates Destination-Host. Basically that would make the agent the scope-authority, rather than the server.