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

[Ben Campbell <[e-mail]>]

Oops, left out a comment--see inline:

On Jul 23, 2013, at 9:11 AM, Ben Campbell <[e-mail]> wrote:

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

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.

> 
> 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.
> 
> 
> On Jul 23, 2013, at 2:57 AM, 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
>>> 
>>> 
>> 
>