Subject: [Dime] Diameter Overload - Default "Implicit" Scope

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

Ben,

Is it possible to define a base default "implicit" Scope, where the Application-ID and the Connection Scopes are mandatory?

We see these two being the minimum to be supported independent of the deployment scenario.

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:07 -0500

Hi Martin,

Technically that should be possible.  I have some concern about mixing implicit and explicit scopes though.  That could be confusing.  I would think it won't be that hard to put those two scopes into control information they apply to. 

Perhaps others have thoughts on mixing implicit and explicit scopes?

Thanks!

Eric

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

> Ben,
>  
> Is it possible to define a base default “implicit” Scope, where the Application-ID and the Connection Scopes are mandatory?
>  
> [email-masked]
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

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

> Perhaps others have thoughts on mixing implicit and explicit scopes?

I think this depends on what we mean by implicit scopes. Is an implicit scope a default that is used if no scope indicators are in an overload report? Or is it a scope that is assumed to be in all reports even if not indicated? I think the first _might_ make sense. The second runs afoul of your concern about mixing implicit and explicit.

In general, though, I lean towards thinking explicit is usually better. I can see some uses for implicit, for example if an IP address is obscured by a NAT, a node might not be able to explicitly indicate its IP address to a peer. But that would be more of an explicit scope indication with an implicit value. For example a Host scope with a value of "whatever IP address you received this request from"

---

From: Eric McMurry <[email-masked]>
Date: Sun, 14 Jul 2013 15:59:06 -0500

> In general, though, I lean towards thinking explicit is usually better. I can see some uses for implicit, for example if an IP address is obscured by a NAT, a node might not be able to explicitly i…
 
The "whatever IP you received this request from" concept could be useful for some other scopes also.  For example, whatever connection you received this request on, or whatever application you received this request on.  I wonder if that would satisfy the use cases that folks are thinking of when they bring up implicit scopes?

---

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

On Jul 14, 2013, at 3:59 PM, Eric McMurry <[email-masked]> wrote:

> The "whatever IP you received this request from" concept could be useful for some other scopes also.  For example, whatever connection you received this request on, or whatever application you received this request on.

I don't think there's any other way to do "connection" to mean anything but "this connection". I guess we could explicitly name a 5-tuple, but I suspect that way leads to madness. OTOH, "this application" could just as easily be named explicitly, so I'm not sure there's a benefit there.

>  I wonder if that would satisfy the use cases that folks are thinking of when they bring up implicit scopes?

I don't know the answer there--that's why I asked a similar question in the previous email :-)

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 16 Jul 2013 09:12:12 +0000

Hi Ben, Eric and all

About the implicit scope, I am thinking to the one used for an overload info which relates to the traffic to which the message transporting this overload info belongs, meaning the traffic between a Destination Host/destination realm, origin Host/origin realm, for a given Application ID. This scope is implicitly defined by these AVPs of the message and does not require a combination of Scope AVPs

Another point is on how to limit the number of scopes and their combinations. Such a number of possibilities increase the complexity of the overload control management, which increases the risks. The implicit scope is an answer to this question as it can be used instead of the other scopes such as Destination Host, Origin Host, application ID, connection, and their combinations in many cases.

Best regards

JJacques

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : lundi 15 juillet 2013 01:04
À : Eric McMurry
Cc : [email-masked]
Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Jul 2013 15:39:18 +0300

> In general, though, I lean towards thinking explicit is usually better. I can see some uses for implicit, for example if an IP address is obscured by a NAT, a node might not be able to explicitly i…

Out of curiosity, would you ever expect NAT between Diameter nodes?
Keeping in mind Diameter is a bidirectional protocol by design a
NAT does not fit in the base protocol.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Jul 2013 09:37:27 -0500

> NAT does not fit in the base protocol.

It has been my experience that we can never assume that some form of NAT won't exist between any two IP hosts, unless you explicitly forbid it. I can see some complications for connection setup, but wouldn't be surprised to see Diameter and/or NAT implementations/deployments figure a way to make it work.

Ben.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 19 Jul 2013 13:07:09 +0000

Hi all

I come back on my mail I sent you last Tuesday on an implicit scope . As I said, I am concerned with the number of scopes and their combinations in the draft-roach solution  which adds complexity, and for this solution I proposed to consider an implicit scope which for me should fit many cases. 

Hannes has a similar concern and in his new solution for overload he focused on a minimal mechanism where there is  no more explicit scopes. Behind this minimal mechanism, there is an implicit scope which I think is not far from mine.

>From these inputs, I think the group should investigate a basic version of the overload control mechanism which could be also part of the draft roach solution and see which extensions are needed. 

Best regards

JJacques

-----Message d'origine-----
De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
Envoyé : mardi 16 juillet 2013 11:12
À : [email-masked]
Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith (Keith)
Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope

Hi Ben, Eric and all

Best regards

JJacques

---

From: Eric McMurry <[email-masked]>
Date: Fri, 19 Jul 2013 08:24:56 -0500

Hi JJaques,

I agree with the general sentiment.  We should make things no more complicated than we need to.  The trick is the "than we need to" part.  There are use cases that could be accomplished with a simple mechanism and fixed scope.  There are other use cases that could be done with a different simple mechanism and a different fixed scope.  Really, we could do that for pretty much any use case, coming up with a set of mechanisms that work for each particular use case.

I would not recommend this approach though, and that's not really what the requirements are calling for.  The potential uses of the mechanism that I have heard from so far also favor a single mechanism.  So, we're left with having to have some flexibility to support different use cases, that need different scopes.  Once we have that, we absolutely should be careful about keeping the complexity to a minimum and that includes the scopes.  There have been several discussions about which scopes are needed for which use cases and what should be mandatory to implement vs. optional and I think these will result in a well thought out, small, set of necessary scopes and an understanding of what optional scopes we need to support some use cases and not others.  Given that we understand that different use cases will benefit from different scopes, I'm not sure that we can get away from having a way to explicitly assign scopes to control information.

So, we get back then to the question of if we can (or should) do both implicit and explicit scopes.  If we do an implicit, default, scope, what use case do we pick for that?  Why is it different than other use cases?  How do we keep that implicit, default, scope from affecting other cases and from confusing implementors?

There were some other threads to foster discussion on specific scopes also.  I think these are good places to explore what we really need and discussion of use cases is really helpful for those.

Thanks,

Eric

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 19 Jul 2013 17:22:26 +0300

> Hannes has a similar concern and in his new solution for overload he focused on a minimal mechanism where there is  no more explicit scopes. Behind this minimal mechanism, there is an implicit scop…

draft-korhonen-dime-ovl-01 also had a set of scopes. When I was thinking the set I would need I settled down to 3 for controlling who can add overload data (and 3 other "scopes" for added information types). I am of an opinion that this is not much, although one can get 63 permutations out of it.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Jul 2013 15:55:07 -0500

> Hannes has a similar concern and in his new solution for overload he focused on a minimal mechanism where there is  no more explicit scopes. Behind this minimal mechanism, there is an implicit scop…

I'm not sure I understand what the implicit scope is in Hannes's draft. 

> From these inputs, I think the group should investigate a basic version of the overload control mechanism which could be also part of the draft roach solution and see which extensions are needed.

I concur we need the most simple solution that meets the requirements. But I think that, without at least some concept of scopes, it's going to be very hard to come up with a mechanism that doesn't do more harm than good. Either it will increase the impact of an overload condition by forcing requests to be rejected unnecessarily, or it will cause clients and relays to attempt to send requests to alternate destinations, which are likely also overloaded.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 19 Jul 2013 21:18:12 +0000

Ben/all,

I believe there could be an "implicit" scope that is common to all use cases (e.g, Application-ID).

Regards,

Martin

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Jul 2013 16:38:25 -0500

By "implicit" scope, are we really talking about a "default" scope? That is, a scope assumed to be active if no scope is reported, but is overridden if any explicit scope is reported?

If so, I don't object in principle. But I think the choice of a default should be the scope that we think will be used the most often. 

You mention Application-Id. That makes sense for a default if you expect Application-Id to actually be selective most of the time, that is, you expect nodes to  send lots of requests with different Application-Ids to the same destination. That's probably true if the destination is an agent that routes request for more than one application. OTOH, do you usually see a client send requests for more than one application on a single transport layer connection?

My kneejerk reaction is to think that the most commonly used scope will be "connection".

OTOH, Application-Id or Connection can each be indicated by a single AVP. Do we gain much in allowing it to be defaulted? JJacques previously mentioned "Destination Host/destination realm, origin Host/origin realm, for a given Application ID", which is a composite that would require 4-5 scope AVPs to express. I don't think that combination would necessarily make a good default, but I can see one might want to be able to express it (and more importantly, negotiate that you can accept that combination, but not other combinations of the same scopes.) We could always add some new scope-type that means "This destination-host, This application-Id", etc. (I'm not suggesting we do so now, but since we intended scopes to be extensible, we could always add that down the road if we find the need to do so.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 22 Jul 2013 02:53:34 +0000

Hello all,

I would support to have an implicit scope limited to what's contained in the message itself, i.e. as mentioned by JJ, specific application, specific host, and specific destination. Or you can call it as a combination of "Destination Host/destination realm, origin Host/origin realm, for a given Application ID". From my point of view, a very simply use case of overload control for 3GPP Diameter applications is that the server sends its load/overload information to the client, the client decides to throttle or not messages related to the corresponding application to the server. E.g. for 3GPP S6a, after update location procedure, the MME would store one specific HSS identity for each UE attached for easy routing of subsequent messages. To this MME, it only cares if this HSS is overloaded. This does not prevent to deploy Diameter Agents for load balancing, which can redirect the requests to other non-overloading servers or change the level of the overload situation of the server. But to the client, it can always see one specific server at a specific time.

Best Regards,
Susan

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 22 Jul 2013 14:23:25 +0000

Hi all

From the different mails exchanged on this topic,

In  the current proposal there are 7 scopes 
	“Connection” 
	“Destination-Realm”
	“Application-ID”
	“Destination-Host”
	“Host”
      “Session”
      “Session Group”
3 are proposed to be mandatory ("Connection", Application-ID”
	“Destination-Host") and a 8 th ("Origin Host") is under discussion 
Then a list of combinations is proposed: 
- 1*(Destination-Realm) and 0*1(Application-ID)
- 1*(Application-ID)  and 0*1(Destination-Realm)
- 1*(Application-ID) and 0*1(Destination-Host)
- 1*(Application-ID) and 0*1(Host)
- 1*(Application-ID) and 0*1(Connection)
- 1*(Destination-Host)
- 1*1(Host)
- 1*1(Connection)
- 1*(Session-Group) 0*1(Host | Connection)
- 1*(Session) 0*1(Host | Connection  

My thinking is this multiplies the number of cases, add complexity and increase risks of IOT issues for critical situations. We are several to think it would be worthwhile to consider an implicit or basic scope that would cover a large number of use cases and to see what would be needed in addition for some particular use cases.

I am proposing an implicit scope. It is not in the above list of scopes and of their combinations. So it would be good to see if it allows to cover many cases, as I think, to significantly reduce the above list. Suzan has highlighted that the implicit scope covers the MME case.  Diameter is largely used for various applications.  What are the known use cases which would not be covered with this implicit scope? 
Hannes is also proposing a basic scope, I think close to mine, and for which we can have the same questioning.

The implicit scope can be used by servers, client and intermediate agents  that can act on it (eg to do message throttling instead of the client). To note that the principle of an implicit scope is not incompatible with explicit scopes and allows any further extensions if new use cases appear to require such extensions
       
Best regards

JJacques

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Shishufeng (Susan)
Envoyé : lundi 22 juillet 2013 04:54
À : Ben Campbell; DOLLY, MARTIN C
Cc : DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry); BERRY, Nigel (Nigel)
Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope

Hello all,

Best Regards,
Susan

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Jul 2013 15:54:06 -0500

> 	“Destination-Host") and a 8 th ("Origin Host") is under discussion

We would not oppose reducing the number of "mandatory" scopes. I'm not sure any really need to be mandatory, as long as you include at least one, and have a way to declare what scopes you are willing to receive.

> Hannes is also proposing a basic scope, I think close to mine, and for which we can have the same questioning.

What scope is Hannes proposing? I didn't find that in the drafts, but may have missed something.

> The implicit scope can be used by servers, client and intermediate agents  that can act on it (eg to do message throttling instead of the client). To note that the principle of an implicit scope is…

Can you elaborate on what you mean by an implicit scope? The two things I can think of is 1) a scope that is considered active if no scope is included in the message (i.e. a "default" scope), or 2) a scope that has an implicit value derived from other characteristics of the request that carries it (e.g. "Connection" takes it's value from the transport layer connection on which the request arrives, rather than from an explicit value that names the connection.) Or do you mean something else entirely?

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Jul 2013 16:07:48 -0500

Hi Susan,

When you say "implicit" scope, do you mean a default? (that is, one that applies if no scope is explicitly included)? I'm not opposed to having such a comment, but I think we need to look more closely at how Diameter servers tend to actually be deployed, and where we save complexity. Realm + Application + Destination-Host + Origin-Host is a fairly complex scope. But the complexity is not in how you express it on the wire--that's pretty easy. It's also not how you interpret the scope--that's a one time action per overload report. The really hard part is the decision function that the reacting node applies to every single request to determine if the scope applies to it. And that's true whether the scope is implicitly or explicitly included in an overload report.

It seems to me that if we define a default scope, it should be both commonly used and simple. The one that you and JJ have proposed may be common, but it's not simple. I think this needs more analysis, but so far I think that "Connection" is the strongest candidate for being both common and simple.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 23 Jul 2013 07:57:08 +0000

Hi Ben,

I'm not sure if "implicit" means "default", but should be very similar to each other on this point.

In my understanding, "Connection" scope focus on transport connection which is limited between two adjacent peers. While in 3GPP Diameter applications, the important thing for overload control is to exchange load/overload between client and server for which there might not be direct transport connection. 

To make things simple and the mechanism defined in IETF more common, I would propose to not have any scope mandated and leave it for applications to decide if explicit scope(s) is(are) needed or an implicit scope can be applied.

Best Regards,
Susan

-----邮件原件-----
发件人: Ben Campbell [mailto:[email-masked]] 
发送时间: 2013年7月23日 5:08
收件人: Shishufeng (Susan)
抄送: DOLLY, MARTIN C; [email-masked]; DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
主题: Re: [Dime] Diameter Overload - Default "Implicit" Scope

Hi Susan,

---

From: Eric McMurry <[email-masked]>
Date: Tue, 23 Jul 2013 10:09:27 +0200

Hi Susan,

Your description of behavior leads me to think you mean default when you are saying implicit.  That is, when no scope is explicitly defined (and only when no scope is explicitly defined), you want a default scope to apply.  

I agree with Ben that a default is probably okay.  One way or another we do need to define the behavior when no scope is specified explicitly.

As to the question of what a default should be, I also agree with Ben that analysis of the use cases would be beneficial here.  For me, connection makes the most sense, since peers are the elements that generally care about overload information and cases with all the topology exposed or with no agents will likely not be the norm (I think that is where we may be seeing things differently).  I am considering primarily 3gpp deployments when making that statement.

For your last statement, I'm a bit confused by your use of "mandated."  I read that along with the rest of the statement as saying there are, or should be, some scopes which are mandatory to use.  That is different than mandatory to support.  I don't think any of the proposals have any mandatory to use scopes (nor should they).  The sender of overload information always chooses an appropriate scope to attach to its information (which could be indicated using a default scope in the protocol, but the sender still has to make a choice).

Thanks,

Eric

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jul 2013 09:11:30 -0500

Hi Susan,

If there is no direct connection, then we are talking about the non-adjacent overload control case. That's not (yet) covered at all in the original two proposals. It's not clear to me if Hannes's proposal is intended to do so.

Have you (and others) had a chance to read the non-adjacent section in draft-campbell-dime-overload-issues-01? The group has had some discussion about the scopes analysis in that draft, but no one has commented much on the non-adjacent overload control analysis.

I am reasonably okay with saying no specific scope is required by the base mechanism, as long as we (continue to) let nodes declare what they can receive. The working group should discuss whether we might want at least one mandatory-to-implement scope to try to avoid "islands" of interoperability. I won't be too unhappy whichever way we go on that, as long as we understand the implications.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jul 2013 09:25:21 -0500

Oops, left out a comment--see inline:

> Have you (and others) had a chance to read the non-adjacent section in draft-campbell-dime-overload-issues-01? The group has had some discussion about the scopes analysis in that draft, but no one…

In particular, I do think any "default" scopes would be different for non-adjacent than adjacent overload control. "Connection" is useless for non-adjacent, but may be the most useful for adjacent. We may need to rule out the Peer (or Host) scope and the Connection scope entirely for non-adjacent use.

I still have concerns about using a combined scope for the default, though. I'd rather pick something simple to act on, i.e. not requiring the reacting node to luck at several aspects of a request to determine if it matches the scope. Essentially, I'm concerned about _defaulting_ to requiring a boolean expression check on each and every request.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jul 2013 09:45:22 -0500

> For your last statement, I'm a bit confused by your use of "mandated."  I read that along with the rest of the statement as saying there are, or should be, some scopes which are mandatory to use.…

It might be better to think of this as "mandatory to send" vs " mandatory to accept". "Mandatory to support" may also be of interest, but if entire sections of the deployment space turn off a feature by configuration, one might as well consider it unsupported.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 23 Jul 2013 16:24:26 -0500

Ben,

It seems prudent to have at least one "mandatory to support" scope.

It also seems to me that the most logical scope for this would be host.  It seems unlikely that there would be different overload state sent on individual connections from a peer.  It is also most likely to be the case that all of the applications handled by the host will be in the same overload state.  

Clearly some implementations might allocate resources on a per application basis and, as such, support overload detection on a appl-id scope.  The more likely implementation is to have shared resources that experience the same overload events.

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 24 Jul 2013 12:59:45 +0000

Dear all

I hereafter add some comments on two ones made in previous mails.

- there was the comment " I'm not sure I understand what the implicit scope is in Hannes's draft"..  I agree it would be good Hannes to clarify his new proposal. From my own reading in draft-tschofenig-dime-overload-piggybacking in  3.2:
   ... the Diameter
   server (or a proxy, ....) may decide to communicate to the Diameter
   client to reject some or even all Diameter requests. The Diameter
   server does so by adding the Overload-Info AVP, which contains the
   Overload and the Period-Of-Validity AVP.

Then the overload AVP indicates to the client the amount of traffic to decrease or to increase. So from my understanding, it is similar to the implicit scope I have described as the piggybacked overload info is related to the message transporting it, and in consequence does not require to indicate an explicit scope. 
I have other views on the content of the overload info where  I am in favour of an overload info indicating a % of traffic reduction to be applied. I also consider the overlaod info is used by the throttling entity which may be the client or an intermediate DA. Hannes only mentions the client.

- about the comment "do you mean a default? (that is, one that applies if no scope is explicitly included)?". The implicit scope I have described is not a default scope, in the above meaning. It is implicit because it applies to the traffic to which the message conveying the overload info belongs. This scope is not exclusive of other scopes, but for the many cases that it covers by itself,  I do not foresee  to use it in conjunction with others. As mentioned, I would like to know use cases, that this implicit scope will not cover and which other scopes or extensions would be required.

Best regards

JJacques 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 23 juillet 2013 16:25
À : Shishufeng
Cc : DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Jul 2013 17:22:41 -0500

Hi JJaques, see comments inline:

> Then the overload AVP indicates to the client the amount of traffic to decrease or to increase. So from my understanding, it is similar to the implicit scope I have described as the piggybacked ove…

Do I understand correctly that you assume the traffic that should be reduced is the set of future requests that have the same realm, application-Id, and perhaps destination-host/origin-host that matches that of the message containing the overload report? I don't recall seeing text in the draft to indicate that, but might have missed something. (If I did, please don't hesitate to educate me :-)  )

> I have other views on the content of the overload info where  I am in favour of an overload info indicating a % of traffic reduction to be applied. I also consider the overlaod info is used by the…

That would be similar to what is in draft-roach-dime-overload-ctrl, when used with the included "loss" algorithm, right? (ignoring for the moment issues of crossing non-supporting agents)

> - about the comment "do you mean a default? (that is, one that applies if no scope is explicitly included)?". The implicit scope I have described is not a default scope, in the above meaning. It is…

The Roach draft currently has a "Connection" scope that takes it's value from the connection on which the report arrived. It's an explicitly included scope, but it's value is implicit. Is that the sort of thing you have in mind, but for a different set of implicit values? That is, we could have sort of a "this realm and application" scope? You would explicitly include it, but the realm and application-ID values would be implied by the message contents?

Thanks!

Ben.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 29 Jul 2013 06:45:24 +0000

Hi Ben, Eric,

Coming back to the implicit or default Scope issue.

Whatever it is called as "implicit" or "default", my intention was that for 3GPP applications, at least e.g. for S6a/S6d, there is no need to have such an explicit Scope parameter to indicate the "scope" for which the overload information applies.

My understanding of the two wording in the context here are very similar, but if we have to differentiate them, "implicit" is more proper to be used for the case we are addressing, which means there is no need to have such a Scope defined, the overload information applies implicitly to the scope implied by the information contained in the message.

In the clause 5.2.3 for definition of Overload AVP in the "Diameter Overload Architecture and Information Model" draft, the last sentence says:

   The increase and decrease of the sending rate refers to new requests
   to the same realm and the same application ID as the message carrying
   the overload information.

which may imply such an implicit scope we are talking about. Hannes may provide his interpretation.

Best Regards,
Susan

-----邮件原件-----
发件人: Ben Campbell [mailto:[email-masked]] 
发送时间: 2013年7月26日 6:23
收件人: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
抄送: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
主题: Re: [Dime] Diameter Overload - Default "Implicit" Scope

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 29 Jul 2013 09:56:19 +0200

> My understanding of the two wording in the context here are very similar, but if we have to differentiate them, "implicit" is more proper to be used for the case we are addressing, which means ther…

I think we can define "default" to mean a scope used if nothing else is specified, and "implicit" to mean the the receiver infers the scope value(s) from the message, rather than having an explicit value indicated in the scope. I think the scope you are asking for is "implicit", and it might also be "default" (although I would still argue that the best default, at least for adjacent peer connections, is "connection").

> which may imply such an implicit scope we are talking about. Hannes may provide his interpretation.

I agree with your interpretation. Apologies, I missed that on first reading, and was looking for it in Hannes's mechanism draft instead of the architecture draft.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 29 Jul 2013 08:06:25 +0000

Hi Ben

The implicit scope I refer to (as well as Suzan) is effectively the one related to the flow of requests that matches that of the message containing the overload report. I would like this scope be part of the solution, but the current draft, as you underlined, does not refer to this scope. We will further discuss it during the IETF 87 meeting.

Best regards

JJacques 

-----Message d'origine-----
De : Shishufeng (Susan) [mailto:[email-masked]] 
Envoyé : lundi 29 juillet 2013 08:45
À : Ben Campbell; TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope

Hi Ben, Eric,

Best Regards,
Susan

-----邮件原件-----
发件人: Ben Campbell [mailto:[email-masked]] 
发送时间: 2013年7月26日 6:23
收件人: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
抄送: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
主题: Re: [Dime] Diameter Overload - Default "Implicit" Scope

Thanks!

Ben.

---

From: Eric McMurry <[email-masked]>
Date: Mon, 29 Jul 2013 10:21:01 +0200

Hi Susan,

So, I think you are asking for a default scope (also a combined scope) that uses implicit information.  That is, you want a scope that applies when there are no scopes called out (default) and you want it to use information derived from other parts of the message it's piggybacked on (implicit).

I have no issue with the concepts here in general.  I think picking something specific to S6 may not be the best approach though.  I started trying to enumerate the scenarios and the useful scopes to go with them to see if there was a default that would be useful in many cases, but the number of ways that scopes would be used for various scenarios (not just topologies, different scopes make sense for different things on the same topology and connections) that there was no obvious answer.

Ben has proposed the ability to specify an implicit value on scopes where that makes sense (I forget his list, but I think there are several scopes this could be done for).  This makes sense and I think would catch what you are after (as well as I understand it) for that part.  For the default part, I think more analysis is needed.  I am not convinced that there is anything reasonable here (there are too many cases and defaults would be different for different topologies/scenarios) or that having to put a scope on control information is really an issue (this sounds like a few lines of code to me).

Thanks,

Eric

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 29 Jul 2013 11:36:23 +0300

I have been rather confused about this implicit scope so far. So let me try to understand what you mean by it:

You want to setup a "scope" without defining how the box comes up with the set of information used to bind the commands to the scope? Rather, a request that contains overload information sets up a scope if one does not exist yet and by some magic the node picks up a set of AVPs (or other information) that it uses as a "key" for scope matching.. After that all commands that match to this undefined set of information determine the scope? You really never want to explicitly describe the information set that is used to match against the implicit scope? Am I right? What is the lifetime of the implicit scope?

- Jouni

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 29 Jul 2013 09:24:21 +0000

Hi Eric,

S6 is just an example, however, it seems that the implicit scope we proposed can be applied to other 3GPP Diameter applications as well. Or I would ask if there are other cases which cannot be covered by the implicit scope? Similar question as raised by JJ in previous mail.

Best Regards,
Susan

-----邮件原件-----
发件人: Eric McMurry [mailto:[email-masked]] 
发送时间: 2013年7月29日 16:21
收件人: Shishufeng (Susan)
抄送: Ben Campbell; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry); BERRY, Nigel (Nigel)
主题: Re: [Dime] Diameter Overload - Default "Implicit" Scope

Hi Susan,

Thanks,

Eric