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

[Eric McMurry <[e-mail]>]

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


On Jul 23, 2013, at 9:57 , Shishufeng (Susan) <[e-mail]> wrote:

> 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:[e-mail]] 
> 发送时间: 2013年7月23日 5:08
> 收件人: Shishufeng (Susan)
> 抄送: DOLLY, MARTIN C; [e-mail]; DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
> 主题: Re: [Dime] Diameter Overload - Default "Implicit" Scope
> 
> 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.
> 
> 
> 
> On Jul 21, 2013, at 9:53 PM, Shishufeng (Susan) <[e-mail]> wrote:
> 
>> 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
>> 
>> -----邮件原件-----
>> 发件人: Ben Campbell [mailto:[e-mail]] 
>> 发送时间: 2013年7月20日 5:38
>> 收件人: DOLLY, MARTIN C
>> 抄送: [e-mail]; DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
>> 主题: Re: [Dime] Diameter Overload - Default "Implicit" Scope
>> 
>> 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.
>> 
>> 
>> On Jul 19, 2013, at 4:18 PM, "DOLLY, MARTIN C" <[e-mail]> wrote:
>> 
>>> Ben/all,
>>> 
>>> I believe there could be an "implicit" scope that is common to all use cases (e.g, Application-ID).
>>> 
>>> Regards,
>>> 
>>> Martin
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ben Campbell
>>> Sent: Friday, July 19, 2013 4:55 PM
>>> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>>> Cc: DRAGE, Keith (Keith); [e-mail]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
>>> Subject: Re: [Dime] Diameter Overload - Default "Implicit" Scope
>>> 
>>> 
>>> On Jul 19, 2013, at 8:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]> wrote:
>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>>>> 
>>>> 
>>>> Best regards
>>>> 
>>>> JJacques
>>>> 
>>>> -----Message d'origine-----
>>>> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
>>>> Envoyé : mardi 16 juillet 2013 11:12
>>>> À : [e-mail]
>>>> Cc : BERRY, Nigel (Nigel); Bessis, Thierry (Thierry); DRAGE, Keith (Keith)
>>>> Objet : RE: [Dime] Diameter Overload - Default "Implicit" Scope
>>>> 
>>>> 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 : [e-mail] [mailto:[e-mail]] De la part de Ben Campbell
>>>> Envoyé : lundi 15 juillet 2013 01:04
>>>> À : Eric McMurry
>>>> Cc : [e-mail]
>>>> Objet : Re: [Dime] Diameter Overload - Default "Implicit" Scope
>>>> 
>>>> 
>>>> On Jul 14, 2013, at 3:59 PM, Eric McMurry <[e-mail]> wrote:
>>>> 
>>>>> 
>>>>> On Jul 14, 2013, at 13:01 , Ben Campbell <[e-mail]> wrote:
>>>>> 
>>>>>> On Jul 14, 2013, at 9:41 AM, Eric McMurry <[e-mail]> wrote:
>>>>>> 
>>>>>>> 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?
>>>>>> 
>>>>>> 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"
>>>>>> 
>>>>> 
>>>>> 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 :-)
>>>> _______________________________________________
>>>> DiME mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>> 
>> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime