Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 7 Mar 2013 12:43:37 +0000

Hi all

I am coming back to the REQ2 discussion we had a few weeks ago and for which there is no yet consensus.
In parallel, in the context of the 3GPP work about Diameter overload, there was an email thread on this REQ2 topic.  I reformulate hereaftger my last comment which I did in this 3GPP discussion and  which is in the continuity of the proposal to DIME that Laurent did on  Jan 24th and of my Feb 8th  comment so that DIME List may express their views,  in particular for the Orlando IETF meeting.

1.         REQ2 currently only says "The mechanism MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support". The word Regardless is ambiguous. An interpretation is to understand it as "independent of" the Diameter applications, meaning Diameter application are not involved in the overload control. This statement may be valid for some Diameter applications (it is why there is the word "allow"),   but there are other cases, especially in 3GPP environment, where other Diameter applications must be aware of the overload situation, especially when the nodes support  a large amount of UEs  towards which they have to accurately drive the UE behaviour in overload situations.
It is why it is proposed to add "The mechanism MUST allow Diameter clients to be aware of an overload situation".
 If we have not this statement in REQ2, there is no REQ to which we can refer to support these essential 3GPP cases, as the current REQ2 cannot apply. The current REQ 2 is here incomplete and I think it is not acceptable in its current writing.

2.       Besides the case of a  DA supporting topology hiding, there are other cases that must be supported
a)       the mechanism must work with a network where there is no intermediate DA (as described in the overload scenarios of the IEFT draft) and here  it is the  end Diameter node that will receive the overload info, and as a client has to handle this overload situation (cf point1)

b)       Similar to the above there is the case of networks with intermediate DAs with limited functions  (eg for routing purposes and without topology hiding) and which are not upgraded for overload support. Here also the mechanism must support this case, overload being handled (as in a) above) between server and clients as no identified differences. If this case is excluded, it imposes a high constraint to the operator to have all the DAs to support the mechanism. This case, for me, is not excluded of the draft and relies on the REQ 35 that applies. But as this deployment case must be supported, it means that the mechanism must work when intermediate nodes are not supporting overload control. It is why we have proposed REQ35 to be with a MUST instead of a SHOULD (as Laurent wrote in his Jan 24th  mail.

3.       about the hiding topology DA case, such a DA plus the hidden servers behind will appear as a "global server" to the clients. In this case the DA will have to support the mechanism in order to define if the "global server" is overloaded and if yes to generate   the overload information associated to this "global server" and transmit it to the clients which then may act according to point 1) . So the DA case with topology hiding is quite compatible with the point  1 and with the proposed requirement "The mechanism MUST allow Diameter clients to be aware of an overload situation "

Best regards

JJacques

De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : vendredi 8 février 2013 15:01
À : [email-masked]
Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Eric

About the REQ2 with the addition of : The mechanism MUST allow Diameter applications to be aware of an overload situation.
I think it is a central point of discussion. Regarding the usage of Diameter in 3GPP environment which is my concern, as Laurent,  I consider that the client  at the source of Diameter requests  (so not an intermediate DA) has to be involved in an overload situation, not only to reduce the traffic as such but on the way it will do it. Quite often in a 3GGP case, the involved Diameter  client will have to trigger some behavior towards the mobile terminals . Whatever the way overload handling  is implemented in the client and the role of the Diameter stack , the triggering of UE behavior will be at the application level, which then has to be aware of the overload situation (so the above additional statement in REQ2).
A second point behind this statement, is that, if requested, the overload information must be propagated up to the Diameter client for an accurate handling  and not to be stopped by an intermediate agent who considers it handles the overload by itself  and does not need to propagate the overload information  upstream.

I don't say that it is systematic and in 3GPP it will depend of the application case, it is why we write "must allow".

Best regards

JJacques

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 7 Mar 2013 11:57:33 +0000

Hi all

I am coming back to the REQ2 discussion we had a few weeks ago and for which there is no yet consensus.
 In parallel, in the context of the 3GPP work about Diameter overload, there was an email thread on this REQ2 topic.  I reformulate here my last comment which I did in this 3GPP discussion and   which is in the continuity of the comments Laurent and I did  in  Jan 24th and Feb 8th  hereafterr mails so that DIME List may express their views,  in particular for the Orlando IETF meeting.

b)       Similar to the above there is the case of networks with intermediate DAs with limited functions  (eg for routing purposes and without topology hiding) and which are not upgraded for overload support. Here also the mechanism must support this case, overload being handled (as in a) above) between server and clients as no identified differences. If this case is excluded, it imposes a high constraint to the operator to have all the DAs to support the mechanism. This case, for me, is not excluded of the draft and relies on the REQ 35 that applies. But as this deployment case must be supported, it means that the mechanism must work when intermediate nodes are not supporting overload control. It is why we have proposed REQ35 to be with a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th  mail.

Best regards

JJacques

________________________________
De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : vendredi 8 février 2013 15:01
À : [email-masked]
Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Eric

Best regards

JJacques

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of THIEBAUT, LAURENT (LAURENT)
Sent: jeudi 7 février 2013 20:11
To: Eric McMurry
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hello Eric

Thanks for your feedback

Trying to reformulate

1) About Req 2: I meant that the mechanisms to carry Diameter overload must be able to carry this information up to the Diameter peer nodes (Diameter client/server)

2) Based on your feedback, I understand that indeed having a dedicated requirement for emergency is too much. This is why I suggested the rewording of an informative  sentence in Req26 as follows:
For example, it may be more beneficial to process messages for existing sessions ahead of new sessions, and it is required to give priority to requests associated with emergency sessions or with high priority users.

3) As long as it is agreed/understood by the Dime group that "the possibility of passing overload information via intermediate agents that do not support the extension" is required, I am fine.

Best Regards

Laurent
ALCATEL-LUCENT

________________________________
De : Eric McMurry [mailto:[email-masked]]
Envoyé : jeudi 7 février 2013 16:00
À : THIEBAUT, LAURENT (LAURENT)
Cc : Ben Campbell; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Laurent,

Thanks for the responses.  Please see comments inline.

Eric

On Feb 7, 2013, at 8:10 , "THIEBAUT, LAURENT (LAURENT)" <[email-masked]<mailto:[email-masked]>> wrote:

Hello all
Thanks Eric and Ben. I owe you some further answers and comments (LTH2) and apologize for being a  bit late.
Please consider them inline starting with LTH2 and consider they are NOT aiming at pushing any solution.

Best Regards
Laurent
ALCATEL-LUCENT

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]<http://nostrum.com/>]
Envoyé : jeudi 31 janvier 2013 00:48
À : Eric McMurry; THIEBAUT, LAURENT (LAURENT)
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi, please see comments inline.

(Apologies for the late response--I'm catching up on email after vacation.)

On Jan 24, 2013, at 1:04 PM, Eric McMurry <[email-masked]<mailto:[email-masked]>> wrote:

> Thanks Laurent.
>
> comments inline.
>
>
> Eric
>
>
> On Jan 24, 2013, at 9:27 , "THIEBAUT, LAURENT (LAURENT)" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>
>>
>> Hello all
>> Please find below our remarks on draft draft-ietf-dime-overload-reqs-03 about Diameter Overload Control Requirements
>>
>> These remarks address topics we have already addressed over Dime but for which we think some enhancements to the text is needed.
>> We hope to converge quickly as we believe that based on these small enhancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved forward into the IETF standardization process.
>>
>> 1.    REQ 2:   The mechanism MUST allow Diameter nodes to support overload
>>             control regardless of which Diameter applications they
>>             support. The mechanism MUST allow Diameter applications
>> to be aware of an overload situation.
>> We believe that a proper handling of a Diameter server overload is to report it at the level of its Diameter client applications in order for them to take proper decisions. This may mean to send signalling towards non Diameter entities.
>> This may relate with the comment made by Hannes.
> As in the current draft, do you think this requirement can be interpreted to say that a diameter stack should handle overload without application intervention and that implementations of overload control mechanisms are required to act in that fashion?
>
> I'm struggling a bit with this since I'm reading it as a requirement on implementations of the overload control mechanism (as opposed to requirements on the specification of the mechanism).  Is it reasonable to require a stack to not handle overload control by itself?

My personal opinion is that the draft should not talk about software architecture--just protocol behavior.

OTOH, I'm not sure if Laurent meant to refer to the separation between the Diameter application and stack on a Diameter node, or the client application that Diameter is supporting.  If the second, I agree putting a few words to that effect could be useful.  (For example, if the Diameter client at a NAS cannot successfully perform an authorization, it might have to cleanly reject a network attachment attempt. The details of that rejection would be out of scope for the overload control mechanism, but the client would still need to Do the Right Thing)
[LTH2] This means that the mechanisms to carry Diameter overload shall be able to carry this information up to the Diameter application within the Diameter peer node (Diameter client/server)

[em]   I think I still don't understand the requirement here.  It sounds like an implementation detail to me.  If we were to require that an overload control mechanism provide some information to an application above it (note that application can mean multiple things here), then the overload control mechanism would have to provide some sort of application level API to comply, right?  I think implementations are likely to do this anyways, but it doesn't need to be done in an interoperable fashion (that would require specification).  I may still be missing your point though.

>>
>>
>>
>>
>>
>> 2.       We recommend to add following requirement:
>> REQ xx:  The overload control mechanism MUST allow networks to properly support Diameter signalling related with emergency and/or priority users.
>> This aspect is mentioned in Req 26 but only as a general guidance while this is a strong operational requirement.
>> "For example, it may be more beneficial to process messages for
>>             existing sessions ahead of new sessions, or to give priority
>>             to requests associated with emergency sessions or with high
>>             priority users."
>
> What does this mean for a mechanism?  How would it be done?

This seems to me to be more like a more application specific requirement than a generic Diameter requirement. If so, I think that would be better specified in whatever document might exist to specify how a particular application might incorporate the overload control mechanism. (For example, in a 3GPP document.)
[LTH2] Even though this is not listed as a requirement with a number "Req xx", it is important that the definition of the protocol that carries Diameter overload information keeps this important guideline in mind.
Req 26 states "For example, it **may** be more beneficial to process messages for existing sessions ahead of new sessions, or to give priority to requests associated with emergency sessions or with high priority users.  ". While "may" is OK for the priority for existing sessions, it is too weak for the "emergency sessions or high priority users".
Would following wording within REq26 be acceptable:
For example, it may be more beneficial to process messages for existing sessions ahead of new sessions, and it is required to give priority to requests associated with emergency sessions or with high priority users.

[em] I think taking out the emergency services example may be a good solution here.  The definition of what to do with emergency message is probably best left to specifications that deal with that directly.

>>
>>
>>
>>
>> 3.    REQ 35:  The mechanism SHOULD provide a method for exchanging
>>             overload and load information between elements that are
>>             connected by intermediaries that do not support the
>>             mechanism.
>> We recommend to replace "The mechanism SHOULD provide a method" by "The mechanism MUSTprovide a method"  as it is a key requirement for deployments especially via intermediate networks.
>
> Personally, I'm on the fence here.  The main issue I have is that any end to end, or end to information source method that passes through intermediaries that don't support the mechanism brings with it an absolute requirement for end to end security.  Given the state of end to end security, this will cause substantial delay to deployment of overload control.  There is a middle ground where a mechanism that could support end to end is required to only be used hop by hop without end to end security in place.  That may be compatible with the suggested change to the requirement but it will have to be considered.
>
> There is also the consideration that a mechanism that requires hop-by-hop action for overload control could be a reasonable or necessary approach, given the potential complexity of the networks involved and the implications of that on what the overload information contains.
>
> At any rate, if the change is made, we must also add the additional security requirement ensuring that the mechanism is not used without end to end security (this is implied by REQ 28, but it needs to be made explicit).

I think I concur with Eric here--there's a potential for some surprises here.  I think we need more analysis of the security and architectural implications of true hop-by-hop vs allowing non-adjacent nodes to communicate overload information. I wonder if we can delegate that to the actual mechanism work, or a separate document than this one?

[LTH2]I'd insist on this as otherwise it prevents Diameter overload information to be passed via intermediate networks (e.g. IPX) that do not yet support the Diameter overload information related protocol. Is a Diameter Agent required to understand all Diameter AVP? Especially when they would not be tagged as NOT Mandatory?

[em]  I don't understand the last part of your statement.  Are you referring to a piggybacked approach to conveying the overload information?  (I understand you are not advocating any particular solution.  I'm just trying to understand your questions)

As to the general point though, as I said earlier, I'm fine with making this a must as long as e2e security is also a must.  I don't think there is agreement on making e2e security a must though, and I would certainly rather not do that.  Perhaps we can tie that requirement directly to this one.  For example:

REQ 35:  The mechanism MUST provide a method for exchanging
             overload and load information between elements that are
             connected by intermediaries that do not support the
             mechanism.  Any exchange of overload and load information between
           non-adjacent nodes MUST be encrypted for the full path between the
           non-adjacent nodes and have the source of the information verified.

My preference though is still to leave this as is, so further analysis can be done as part of the mechanism work.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 7 Mar 2013 12:09:10 +0000

Hi all

I am coming back to the REQ2 discussion we had a few weeks ago and for which there is no yet consensus.
In parallel, in the context of the 3GPP work about Diameter overload, there was an email thread on this REQ2 topic.  I reformulate here my last comment which I did in this 3GPP discussion and   which is in the continuity of the comments Laurent and I did to DIME in  Jan 24th and Feb 8th  hereafter mails so that DIME List may express their views,  in particular for the Orlando IETF meeting.

Best regards

JJacques

Hi Eric

Best regards

JJacques

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de THIEBAUT, LAURENT (LAURENT)
Envoyé : jeudi 24 janvier 2013 16:27
À : [email-masked]
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hello all

            priority users."

            mechanism.

We recommend to replace "The mechanism SHOULD provide a method" by "The mechanism MUST provide a method"  as it is a key requirement for deployments especially via intermediate networks.

4.       We recommend to add following requirement

REQ yy:  The mechanism MUST support a default overload algorithm. This will facilitate interoperability especially between Networks.

5.    REQ 33:  There are multiple situations where a Diameter node may be

            overloaded for some purposes but not others.  For example,

            this can happen to an agent or server that supports multiple

            applications, or when a server depends on multiple external

            resources, some of which may become overloaded while others

            are fully available.  The mechanism MUST allow Diameter

            nodes to indicate overload with sufficient granularity to

            allow clients to take action based on the overloaded

            resources without forcing available capacity to go unused.

            The mechanism MUST support specification of overload

            information with granularities of at least "Diameter node",

            "realm", "Diameter application", and "Diameter session", and

            SHOULD allow extensibility for others to be added in the

            future.

a.       We recommend to replace "SHOULD allow extensibility" by "MUST allow extensibility" .

b.       We are not sure that the granularity at Diameter session is really required and suggest to remove it from this Req 33.

Best Regards

Laurent
ALCATEL-LUCENT

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Mar 2013 15:36:09 -0600

Hi Jean-Jacques, please see comments inline:

On Mar 7, 2013, at 5:57 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> wrote:

> 1.         REQ2 currently only says “The mechanism MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support”. The word Regardless is ambiguous. An interpretation is to understand it as “independent of” the Diameter applications, meaning Diameter application are not involved in the overload control. This statement may be valid for some Diameter applications (it is why there is the word “allow”),   but there are other cases, especially in 3GPP environment, where other Diameter applications must be aware of the overload situation, especially when the nodes support  a large amount of UEs  towards which they have to accurately drive the UE behaviour in overload situations.
> It is why it is proposed to add “The mechanism MUST allow Diameter clients to be aware of an overload situation”.

I think some of the issue so far has been in the definition of "Application". The requirements draft uses the term "Diameter Application" to refer to the collection of commands and semantics defined by an application ID, and that can be negotiated during the capabilities exchange phase of a connection. I don't think that's quite the same sense that you have in mind--I gather you are thinking in more of a software architecture/layering sense. We didn't intend the requirement to assume anything about software architecture and implementation.

Would it make more sense if the requirement said something along the lines of "... regardless of which Application IDs they support?"

As far as the need for the requirement about clients being aware of overload--I think it makes more sense to state that in terms of the needed results. What about something to the effect of:

"Diameter clients must be able to receive sufficient information to support graceful behavior in their client applications during an overload condition"?  

By "client application", I mean the thing the client  does that needs Diameter in the first place--in your example, it's the "driving UE behavior" part. (I'm open to suggestions for better words than "client application")

> a)       the mechanism must work with a network where there is no intermediate DA (as described in the overload scenarios of the IEFT draft) and here  it is the  end Diameter node that will receive…

Agreed. I don't think we ever intended to accept a solution that _required_ agents. So what if we add a requirement to the effect of:

The solution MUST work in the absence of intervening Diameter agents.

> b)       Similar to the above there is the case of networks with intermediate DAs with limited functions  (eg for routing purposes and without topology hiding) and which are not upgraded for overlo…

There have been arguments on both sides of whether 35 should be a MUST or a SHOULD. I think those leaning towards a SHOULD are thinking that this may be hard problem to solve in the general case. Putting a SHOULD there would create a preference for a solution that did solve this, vs a solution that did not, everything else being equal.

I think I would be willing to accept a MUST there, if we understand that there may be significant limitations in how much an agent can do and significant requirements for information sharing and among servers upstream of the agent (e.g. any server may be required to speak for all servers.) 

We may also find that a different mechanism is required to bypass an agent than would normally be used if the agent actually supported overload control. For example, negotiating support between non-adjacent nodes may be tricky given existing (and proposed) negotiation mechanisms.

I hope to discuss this as an open issue in Orlando.

>  
> 3.       about the hiding topology DA case, such a DA plus the hidden servers behind will appear as a “global server” to the clients. In this case the DA will have to support the mechanism in order to define if the “global server” is overloaded and if yes to generate   the overload information associated to this “global server” and transmit it to the clients which then may act according to point 1) . So the DA case with topology hiding is quite compatible with the point  1 and with the proposed requirement “The mechanism MUST allow Diameter clients to be aware of an overload situation “

My comment to number 2 probably also needs the following for the sake of completeness:

The solution MUST work in the presence of one or more intervening Diameter Agents, including those that hide the upstream network topology.

Please see my comment to 1 concerning the "MUST allow Diameter Clients..." part. Also, keep in mind the downstream peer of this "global server" may also be an agent.

[...]

Thanks!

Ben.

---

From: <[email-masked]>
Date: Mon, 11 Mar 2013 15:57:55 +0000

Hi,

For this discussion, it might be useful to refer to the definition given in the RFC6733:

   Diameter Client

      A Diameter client is a Diameter node that supports Diameter client

      applications as well as the base protocol.  Diameter clients are

      often implemented in devices situated at the edge of a network and

      provide access control services for that network.  Typical

      examples of Diameter clients include the Network Access Server

      (NAS) and the Mobile IP Foreign Agent (FA).

   Proxy Agent or Proxy

      In addition to forwarding requests and responses, proxies make
      policy decisions relating to resource usage and provisioning.
      Typically, this is accomplished by tracking the state of NAS
      devices.  While proxies usually do not respond to client requests
      prior to receiving a response from the server, they may originate
      Reject messages in cases where policies are violated.  As a
      result, proxies need to understand the semantics of the messages
      passing through them, and they may not support all Diameter
      applications.

For further comments, please see below.

Regards,

Lionel

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> De la part de Ben Campbell
Envoyé : jeudi 7 mars 2013 22:36
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : DRAGE, Keith (Keith); [email-masked]<mailto:[email-masked]>; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

On Mar 7, 2013, at 5:57 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all

   [LM] referring to the definition given above, the second "client application" seems redundant. The text could simply be:

   "Diameter clients must be able to receive sufficient information to support graceful behavior during an overload condition"

   [LM] we could have something even more generic using: "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers".

   [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution designers that the preference will be given to the solution that would provide this feature, not as an absolute constraint.

   [LM] i think that my proposal in comment 2 covers this text, saying that the part referring explicitly to  network topology hiding is not deemed required (as a proxy can do whatever, and topology hiding is only one example of possible functions provided by the proxy.

   [...]

   Thanks!

   Ben.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 11 Mar 2013 12:46:23 -0400

Hi Lionel,

Those were the definitions I was trying to use, since we've had some confusion about scenarios where a proxy looks like a server to a client, or like a client to a server. While those scenarios are real, the proxy is still not a server or client according to RFC 6733.

More inline:

[...]

> "Diameter clients must be able to receive sufficient information to support graceful behavior during an overload condition"

I'm okay with that change. I was looking for a word that described the "application" that a client uses at the edge of the network for its own customers, to handle things like network attachments. That is, something distinct from the "Diameter application". But I agree that the requirement can stand without it.

> [LM] we could have something even more generic using: "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers".

I'm happy to combine it that way. I only separated this to follow the structure of the original email.

> [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution designers that the preference will be given to the solution that would provide this feature, not as an absolute constraint.

I concur, and I'm reasonably okay with either choice. (From a practical perspective, the distinction between SHOULD and MUST is smaller when writing a requirements document than for a protocol specification. The working group can later discover that a requirement simply won't work, or is not worth the tradeoffs either way.)

> I hope to discuss this as an open issue in Orlando.

I've got it in the in-progress slide deck that I am racing to get to the chairs :-)

> [LM] i think that my proposal in comment 2 covers this text, saying that the part referring explicitly to  network topology hiding is not deemed required (as a proxy can do whatever, and topology h…

I agree in general, although there may be some instances of "whatever" that OC can't work across--for example, a proxy that deliberately hides overload information.

> Please see my comment to 1 concerning the "MUST allow Diameter Clients..." part. Also, keep in mind the downstream peer of this "global server" may also be an agent.

Agreed. I intended to write "one or more agents", but somehow failed to do so.

Thanks!

Ben.

---

From: <[email-masked]>
Date: Mon, 11 Mar 2013 17:06:42 +0000

Thank you for this answer.

One small comment on (not to open a new thread):

"I agree in general, although there may be some instances of "whatever" that OC can't work across--for example, a proxy that deliberately hides overload information."

Proxy means "advertising support of application-id X". So it is up to the documentation using this application to describe what should do the proxy, "whatever" the functions provided by this proxy. So it is also up to the application designers to figure out what to do with the proxies in the middle, and this includes system in which OC will be supported.

But the general requirement remains: the solution MUST Work in the presence or absence of Diameter agents between Diameter clients and servers! :)

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : lundi 11 mars 2013 17:46
À : MORAND Lionel OLNC/OLN
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Lionel,

More inline:

[...]

Thanks!

Ben.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 11 Mar 2013 21:49:42 +0000

Dear all

I have added some comments starting with [JJ].

Best regards

JJacques 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 11 mars 2013 18:07
À : Ben Campbell
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Lionel

-----Message d'origine-----

Hi Lionel,

More inline:

[...]

[JJ] Initially I used the expression Diameter application. After, from Lionel's suggestion, we wrote "The mechanism MUST allow Diameter clients to be aware of an overload situation" to avoid the use of the word "application", so I do not see why this sentence is not acceptable . On the other point, I do not understand what  is "sufficient information". The information that the Diameter client must receive is simply the overload information that will be defined by IETF for the overload control mechanism (as in point 2 a).

[JJ] I am OK with Lionel

[JJ] As I said, the deployment with DAs not supporting the mechanism must not be excluded, so this implies the solution to support this case and drives to a MUST in REQ 35. Then we will see if we have a solution fulfilling the requirement  

Thanks!

Ben.

---

From: <[email-masked]>
Date: Mon, 11 Mar 2013 22:12:34 +0000

Hi JJ,

Please see below (keeping only the open points).

Regards,

Lionel

[LM] Using wording in REQ1: "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition" 
Would it be acceptable for everybody even if maybe not perfect for everyone?

[LM] I don't understand! A (hypothetical) solution that would use a dedicated signaling channel between nodes supporting overload control and not involving the DAs would also comply with the general requirement for overload control (in theory), right?

---

From: Ben Campbell <[email-masked]>
Date: Mon, 11 Mar 2013 19:16:16 -0400

Hi,

I'm separating out the one really contentious issue:

> [JJ] Initially I used the expression Diameter application. After, from Lionel's suggestion, we wrote "The mechanism MUST allow Diameter clients to be aware of an overload situation" to avoid the us…

It comes down to a difference between requirements and solution.  I don't think any of us know the details of what constitutes "sufficient information" yet. The idea is, to leave it to the solution development effort to figure out exactly what that is. Maybe that shows us that the "sufficient information" is always the OC info sent by the server. But maybe it will be something else, or maybe it will be a mixture. The important point is that it "enables graceful behavior". If people disagree on what the details of what information is sufficient to that goal, that's even a better reason to not over-constrain the solution in the requirement document.

Imagine a solution with the following properties as a though experiment.

1. When a server becomes overloaded, it sends an overload report.
2. If no agent exists, the overload report goes directly to the client.
3. If an agent exists, it attempts to resolve the overload situation locally. (For example, it tries to divert load to another server that has sufficient capacity.) If it's successful, the client _never_ learns the overload condition happened in the first place.
4. If the agent cannot resolve the load locally, it originates its own overload report back toward the client. This report describes the aggregate overload of the agent and the network upstream of it. It is likely to be significantly different than the report originally sent by the server, and may include no information whatsoever from the original report sent by the server.

Would an approach like that meet the requirement you have in mind? Would another approach that guaranteed that the client would see the original server's overload report be preferable?

---

From: <[email-masked]>
Date: Tue, 12 Mar 2013 04:43:58 +0000

Hi Ben

Have you see my proposed wording in response to JJ comment?

Regards,

Lionel

Envoyé de mon iPod

Le 12 mars 2013 à 00:16, "Ben Campbell" <[email-masked]<mailto:[email-masked]>> a écrit :

Hi,

On Mar 11, 2013, at 5:49 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "BERRY, Nigel (Nigel)" <[email-masked]>
Date: Tue, 12 Mar 2013 11:02:10 +0000

Hi Lionel,
See in line,
Kind Regards,
Nigel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 11 March 2013 22:13
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi JJ,

Regards,

Lionel

I'm okay with that change. I was looking for a word that described the "application" that a client uses at the edge of the network for its own customers, to handle things like network attachments. That is, something distinct from the "Diameter application". But I agree that the requirement can stand without it.
[Nigel]
[Nigel] Yes, I do not see the need for more precision especially when "Diameter Client Application" remains undefined and vague, so let's use the term defined, "Diameter Client" this entails the whole box of tricks and all applications supported.

[LM] Using wording in REQ1: "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition"
Would it be acceptable for everybody even if maybe not perfect for everyone?
[Nigel]
[Nigel] This is fine by me. Do we need to be more precise at this stage?

[JJ] As I said, the deployment with DAs not supporting the mechanism must not be excluded, so this implies the solution to support this case and drives to a MUST in REQ 35. Then we will see if we have a solution fulfilling the requirement
[Nigel]
[Nigel] This is a "must" for the normal Client-Server case. In the Proxy case, the Client should also be informed that actions are being taken to subsume an overload situation even if the Proxy attempts to take care of this.

[Nigel] But should we not consider the normal cases before any hypothetical cases.

---

From: "BERRY, Nigel (Nigel)" <[email-masked]>
Date: Tue, 12 Mar 2013 11:11:07 +0000

Hi Ben,
See in line,
Kind Regards,
Nigel

________________________________
From: Ben Campbell [mailto:[email-masked]]
Sent: 11 March 2013 23:16
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc: [email-masked]; DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi,

I'm okay with that change. I was looking for a word that described the "application" that a client uses at the edge of the network for its own customers, to handle things like network attachments. That is, something distinct from the "Diameter application". But I agree that the requirement can stand without it.
[Nigel] Are not these the Diameter Clients?

It comes down to a difference between requirements and solution.  I don't think any of us know the details of what constitutes "sufficient information" yet. The idea is, to leave it to the solution development effort to figure out exactly what that is. Maybe that shows us that the "sufficient information" is always the OC info sent by the server. But maybe it will be something else, or maybe it will be a mixture. The important point is that it "enables graceful behavior". If people disagree on what the details of what information is sufficient to that goal, that's even a better reason to not over-constrain the solution in the requirement document.
[Nigel] How about "sufficient information to enable a graceful behaviour"?

Would an approach like that meet the requirement you have in mind? Would another approach that guaranteed that the client would see the original server's overload report be preferable?
[Nigel] We obviously have to bear in mind that a Diameter proxy may be able to deal with an overload situation of a topology that it is hiding, on the other hand it might not, so in the normal case the Diameter Client must be informed of any overload situation pertaining to the Clients it is responsible for.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 12 Mar 2013 11:35:27 +0000

-----Message d'origine-----
De : BERRY, Nigel (Nigel) 
Envoyé : mardi 12 mars 2013 12:02
À : [email-masked]; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc : DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Lionel,
See in line,
Kind Regards,
Nigel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 11 March 2013 22:13
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi JJ,

Regards,

Lionel

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 12 Mar 2013 11:35:23 +0000

Hi Lionel

I add my remarks with [JJ2]to Nigel'ones.

Best regards

JJacques 

-----Message d'origine-----

Hi Lionel,
See in line,
Kind Regards,
Nigel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 11 March 2013 22:13
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi JJ,

Regards,

Lionel

[JJ2] My important point in my statement is that a Diameter client which wants to support graceful behavior during an overload condition must receive the overload information on which it will base its graceful behavior including a graceful shedding. I have no issue about where load balancing is done (and in practice DAs have a key role there), but if traffic must be reduced (shedding), I have the requirement to allow the Diameter  client to be informed of this overload situation by receiving the overload information so to have  a graceful behavior with graceful shedding rather than to do the shedding in the DA. Otherwise, if this possibility is not offered, I have no graceful behavior because no overlaod info is given to the client, shedding being done by the DA. Do you consider your new wording covers this requirement? If yes, OK, but on my side, I am not yet sure. It is a key point. 

[JJ2] As I also said, my above statement is also  compliant with Ben's example (cf parallel mail) with  an intermediate DA that is doing load balancing to other servers and may solve overload without  traffic shedding. But, if, nevertheless, after load balancing, it remains  a global/aggregated  overload, in this case, I have the same requirement as above  to allow the Diameter  client to be informed of this overload, so that it can have  a graceful  behavior and shedding.    

[Nigel] But should we not consider the normal cases before any hypothetical cases.
[JJ2)] I have not spoken of a dedicated signaling channel; but here we are entering the solutions space. We can imagine solutions where the overload info is simply transferred downstream by a DA not supporting the mechanism    
_________________________________________________________________________________________________________________________

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 12 Mar 2013 11:42:02 +0000

G'day,

I really do not understand why we are splitting hairs, not once but twice....

Regards,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Tuesday, March 12, 2013 7:35 AM
To: [email-masked]; Ben Campbell; BERRY, Nigel (Nigel)
Cc: DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Lionel

Best regards

JJacques 

-----Message d'origine-----

Hi Lionel,
See in line,
Kind Regards,
Nigel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 11 March 2013 22:13
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi JJ,

Regards,

Lionel

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

---

From: "BERRY, Nigel (Nigel)" <[email-masked]>
Date: Tue, 12 Mar 2013 12:00:04 +0000

Hi Lionel, JJ,
Appending comments with Nigel1,
Kind Regards,
Nigel

-----Original Message-----
From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: 12 March 2013 11:35
To: [email-masked]; Ben Campbell; BERRY, Nigel (Nigel)
Cc: DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Lionel

Best regards

JJacques

-----Message d'origine-----
De : BERRY, Nigel (Nigel)
Envoyé : mardi 12 mars 2013 12:02
À : [email-masked]; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc : DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Lionel,
See in line,
Kind Regards,
Nigel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 11 March 2013 22:13
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi JJ,

Regards,

Lionel

[JJ2] My important point in my statement is that a Diameter client which wants to support graceful behavior during an overload condition must receive the overload information on which it will base its graceful behavior including a graceful shedding. I have no issue about where load balancing is done (and in practice DAs have a key role there), but if traffic must be reduced (shedding), I have the requirement to allow the Diameter  client to be informed of this overload situation by receiving the overload information so to have  a graceful behavior with graceful shedding rather than to do the shedding in the DA. Otherwise, if this possibility is not offered, I have no graceful behavior because no overlaod info is given to the client, shedding being done by the DA. Do you consider your new wording covers this requirement? If yes, OK, but on my side, I am not yet sure. It is a key point.
[Nigel1] I see, your point: is "load shedding" graceful behaviour?
I suppose graceful behaviour is everything apart from falling over, in the sense of being drunk. In that case we should just leave it as "sufficient information for appropriate action to be taken".

[JJ2] As I also said, my above statement is also  compliant with Ben's example (cf parallel mail) with  an intermediate DA that is doing load balancing to other servers and may solve overload without  traffic shedding. But, if, nevertheless, after load balancing, it remains a global/aggregated overload, in this case, I have the same requirement as above to allow the Diameter client to be informed of this overload, so that it can have a graceful behavior and shedding.
[Nigel] Yes, it is important that all scenarios are considered and not just an appropriate few.

[Nigel] But should we not consider the normal cases before any hypothetical cases.
[JJ2)] I have not spoken of a dedicated signaling channel; but here we are entering the solutions space. We can imagine solutions where the overload info is simply transferred downstream by a DA not supporting the mechanism
[Nigel1] Yes, good point!

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 09:40:07 -0400

Hi, further comments inline:

On Mar 12, 2013, at 7:35 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> wrote:

[...]

> [JJ2] As I also said, my above statement is also  compliant with Ben's example (cf parallel mail) with  an intermediate DA that is doing load balancing to other servers and may solve overload witho…

If we understand that a requirement for the client to receive overload information doesn't mean it has to receive the information that the server sent, and it doesn't mean it has to receive it at all if an agent 1) exists, and 2) can handle the condition locally and transparently, then I'm reasonably okay with that. But I've seen a few comments that suggest a general preference for handling overload as close to the client as possible. I'm not opposed to it being possible to do so, but I don't want to be prevented from taking a "handle it as close to the server as I can" approach either.

Isn't the actual requirement that the "Client is able to behave gracefully during an overload condition"?

I can think of a number of ways to accomplish that off-hand: 1) Direct client-server connection. 2) Agent completely handles overload without dropping requests. 3) Agent sends an aggregate overload report to the client. 4) Agent drops requests locally, and informs client of dropped requests with an error message. I'm sure there's more.

Each of these might be better or worse than the others--but the criteria should be how well the solution supports graceful client behavior, not the details of how it accomplishes it. (I recognize that option 4 may have issues, but those issues can still be measured according to how well the client can implement graceful behavior.)  Going beyond that is solution, not requirements.

[...]

> _

I don't think we can declare either a direct client-server connection architecture, or an agent based architecture, as the _normal_ case. Both exist in the wild. I agree the solution should work in the direct client-server connection case, but if agents can provide additional value, we should not prejudice the solution effort away from considering that.

Thanks!

Ben.

---

From: <[email-masked]>
Date: Tue, 12 Mar 2013 13:59:26 +0000

Hi,

Honestly, I don't understand why we have to go down each time to the solution space to understand a requirement!
Can we try to make it simple when possible?

1/ REQ 2 complement:

Based on the different comments, my proposal for the new requirement is the following: 
"Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition"

And the question is: OK or NOK i.e. can you live with?

2/ REQ 35:
With the clarification that the "SHOULD" is strong recommendation for solution designers i.e. if you can meet this requirement, your solution will have greater chances to be selected than a solution without, is it acceptable to keep the "SHOULD" in the draft?

OK or NOK? 

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : mardi 12 mars 2013 14:40
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : MORAND Lionel OLNC/OLN; BERRY, Nigel (Nigel); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

[...]

[...]

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 10:43:51 -0400

Hi comments inline:

> Can we try to make it simple when possible?

My solution examples were intended to illustrate that there can be more than one solution approach, and we should be careful not to over-constrain the solution in the requirements. I did not mean for any of them to be assumed as the "real" solution.

> And the question is: OK or NOK i.e. can you live with?

Grudgingly OK, with the provision that this allows but does not require the information to be sent end-to-end from server to client. 

I would be _considerably_ happier with something of the form of "The solution must support graceful client behavior during an overload condition."

> With the clarification that the "SHOULD" is strong recommendation for solution designers i.e. if you can meet this requirement, your solution will have greater chances to be selected than a solutio…

OK.

I would also accept a MUST, with the understanding that there may be limitations on what a non-supporting intermediary can do and still be traversable. 

Have we accepted the requirement(s) about working both with or without agents?

[...]

---

From: <[email-masked]>
Date: Tue, 12 Mar 2013 14:53:00 +0000

Hi Ben,

The requirement on DA in the path or not was agreed in a previous mail by the people involved in this discussion.

About the req2 complement, I think that the strong point is that the client needs to receive info. So keep the text as it is if OK.

For REQ 35, the "SHOULD" seems to better than a "MUST but". It is why I propose to keep the current "SHOULD". And it clearly indicates the preference for a solution supporting such scenarios.

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : mardi 12 mars 2013 15:44
À : MORAND Lionel OLNC/OLN
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi comments inline:

OK.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 11:04:17 -0400

> About the req2 complement, I think that the strong point is that the client needs to receive info. So keep the text as it is if OK.

You've stuck the heart of the "grudging" part of my "OK".  At the risk of further splitting the hair, I think the main point is "graceful behavior". That is, a requirement to "receive info" without a requirement to "support graceful behavior" is insufficient. A requirement to "support graceful behavior" can stand on its own without any requirements about information flow.

> For REQ 35, the "SHOULD" seems to better than a "MUST but". It is why I propose to keep the current "SHOULD". And it clearly indicates the preference for a solution supporting such scenarios.

For the record, I'm okay with "SHOULD". My additional comments were in anticipation of others' NOK.

---

From: <[email-masked]>
Date: Tue, 12 Mar 2013 15:11:16 +0000

Hi Ben,

[LM] this is true for any Diameter peer. You can do a lot of thing without receiving explicit info. But I think that in this document we have to focus on what to do when explicit info is available/received. And this requirement is then correct in this context, right? It does not preclude to adopt a graceful behavior without this info.

Regards,

Lionel

-----Message d'origine-----
Envoyé : mardi 12 mars 2013 16:04

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 11:13:59 -0400

> [LM] this is true for any Diameter peer. You can do a lot of thing without receiving explicit info. But I think that in this document we have to focus on what to do when explicit info is available/…

OK, call it an OK :-)

---

From: "BERRY, Nigel (Nigel)" <[email-masked]>
Date: Tue, 12 Mar 2013 15:33:14 +0000

Hi Lionel,
JJ's laptop is on the blink so I will attempt to answer,
See in-line,
Kind Regards,
Nigel

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 12 March 2013 14:44
To: [email-masked]
Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi comments inline:

My solution examples were intended to illustrate that there can be more than one solution approach, and we should be careful not to over-constrain the solution in the requirements. I did not mean for any of them to be assumed as the "real" solution.
[Nigel] I agree with Ben we have to dip our toe in the water of potential solutions that deal with all scenarios in order to understand the correct wording of requirements.

I would be _considerably_ happier with something of the form of "The solution must support graceful client behavior during an overload condition."
[Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition" providing a necessary consequence of graceful behaviour may involve drastic load shedding at the client or the active proxy.

OK.

I would also accept a MUST, with the understanding that there may be limitations on what a non-supporting intermediary can do and still be traversable.
[Nigel] A number of people prefer the "must" so can we compromise on this use if Ben can accept this, so we can ensure the Client gets the appropriate information so it can act if necessary

Have we accepted the requirement(s) about working both with or without agents?
[Nigel] Ben, I am not sure which Requirement you are referring to but the solution has to work with and without Diameter Agents (stateful or not stateful) involved so any requirement should not disallow these scenarios.

[...]

---

From: <[email-masked]>
Date: Tue, 12 Mar 2013 15:43:37 +0000

Almost the end :)

Remaining issue: REQ35

OK.

[LM] Not so sure about the number of voices for the "MUST"...

[LM] this requirement was agreed: "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers"

-----Message d'origine-----
De : BERRY, Nigel (Nigel) [mailto:[email-masked]] 
Envoyé : mardi 12 mars 2013 16:33
À : Ben Campbell; MORAND Lionel OLNC/OLN
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Lionel,

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 12 March 2013 14:44
To: [email-masked]
Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi comments inline:

OK.

[...]

---

From: "BERRY, Nigel (Nigel)" <[email-masked]>
Date: Tue, 12 Mar 2013 15:59:00 +0000

Hi Lionel,
See in line,
Kind Regards,
Nigel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12 March 2013 15:44
To: BERRY, Nigel (Nigel); Ben Campbell
Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Almost the end :)

Remaining issue: REQ35

OK.

[LM] Not so sure about the number of voices for the "MUST"...
[Nigel]
[Nigel] Can you not check who can not compromise on the use of "must"?

[Nigel] OK, that's fine.

-----Message d'origine-----
De : BERRY, Nigel (Nigel) [mailto:[email-masked]]
Envoyé : mardi 12 mars 2013 16:33
À : Ben Campbell; MORAND Lionel OLNC/OLN
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Lionel,

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 12 March 2013 14:44
To: [email-masked]
Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi comments inline:

OK.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 12:54:50 -0400

> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition" providing a necessary con…

Agreed. I think people understand that "graceful behavior during an overload condition" doesn't mean everything always works normally as if there were no overload. It sometimes means dropped requests, and errors back to end users . We're trying to avoid things like request retry storms, users left hanging, poor prioritization, etc.

---

From: Eric McMurry <[email-masked]>
Date: Tue, 12 Mar 2013 22:41:43 +0100

I have stated before that I am fine with a MUST provided that the requirement for end to end security is also added.  Traversing non-supporint elements without this would be folly

I believe the best compromise here is to leave it as is, so that more thought can be put into this without constraining the solution to something that may be nearly impossible to deploy.  It may also be possible to define the security requirement for specific scenarios where the risk is higher.  This would include a specific requirement (at MUST level) stating that e2e security is required for traversing non-supporting elements.  I believe that this approach is generally consistent with what some have been discussing about using a MUST level on 35 along with constraints.

Eric

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 13 Mar 2013 08:36:06 +0000

Hello all,

Trying to summarize a bit, for my own clarification here and agreement.
I think latest proposals are:

REQ-35:
==========================

REQ-35 (now in draft v.5):
   REQ 35:  The mechanism SHOULD provide a method for exchanging
            overload and load information between elements that are
            connected by intermediaries that do not support the
		mechanism

REQ-35 (proposal):
 "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers"
 
I think there is something to add to reflect everything cover by former requirement:

REQ-35 (new proposal):
 "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, regardless whether or not Diameter agents support the overload control mechanism"

Although this may be considered covered by REQ-16:
   REQ 16:  The overload control mechanism is likely to be deployed
            incrementally.  The mechanism MUST support a mixed
            environment where some, but not all, nodes implement it.

But I presume it does not harm to be explicit here, like in former requirement.

About the comment by Eric on security (just mail below), we need to check then whether REQ-30 need to be modified, or a new requirement shall apply, right?

   REQ 30:  The mechanism MUST NOT depend on being deployed in
            environments where all Diameter nodes are completely
            trusted.  It SHOULD operate as effectively as possible in
            environments where other nodes are malicious; this includes
            preventing malicious nodes from obtaining more than a fair
            share of service.  Note that this does not imply any
            responsibility on the mechanism to detect, or take
            countermeasures against, malicious nodes.

REQ-2 complement:
==========================

First, I could accept the proposal we got now on the table, I do not want to keep discussion forever, but... I'd like to propose some enhancements that I think cover all people concerns stated so far, hopefully without rasing disagreements.

Proposal now is: 

I got some comments on this, taking into account the first proposal was:
"The mechanism MUST allow Diameter clients to be aware of an overload situation "

I think it is better to request that is "the mechanism" the one that should provide the means for the client to be able to do something, since we are specifying what the mechanism shall do in other requirements, like:

   REQ 1:   The overload control mechanism MUST provide a communication
            method for Diameter nodes to exchange load and overload
            information.

Then my -intermediate- proposal would be the following:
"The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation"

Where I think "graceful behavior" is raising some concerns, in facts this is not specific enough in my opinion. Good requirement writing would avoid multiple interpretations. Then, what about this:

New proposal for REQ-2 complement:
"The mechanism MUST allow Diameter clients to act during an overload situation in order to improve it while impacts are minimized"

Best regards
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric McMurry
Sent: martes, 12 de marzo de 2013 22:42
To: [email-masked]
Cc: DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry); BERRY, Nigel (Nigel)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Eric

On Mar 12, 2013, at 16:43 , [email-masked] wrote:

> [Nigel] A number of people prefer the "must" so can we compromise on 
> this use if Ben can accept this, so we can ensure the Client gets the 
> appropriate information so it can act if necessary
> 
> À : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES 
> (JEAN-JACQUES); DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry 
> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
> 
> Hi Lionel,
> JJ's laptop is on the blink so I will attempt to answer, See in-line, 
> Kind Regards, Nigel
> 
> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, 
> Keith (Keith); [email-masked]; Bessis, Thierry (Thierry)
> [Nigel] A number of people prefer the "must" so can we compromise on 
> this use if Ben can accept this, so we can ensure the Client gets the 
> appropriate information so it can act if necessary
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 13 Mar 2013 09:34:42 +0000

HI Maria Cruz

Thanks for your feedback:

About REQ 35, my understanding was that the existing REQ35 wording was kept (with still the pending point between MUST and SHOULD as mentioned in a Nigel's mail), and that a new sentence "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers" would be added. 
You propose for REQ35 "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, regardless whether or not Diameter agents support the overload control mechanism". 

In fact it groups the two sentences with a MUST, so it is OK for me.

You mentioned the REQ16 which I also agree.

========

For REQ2 

About your two proposals
 "The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation"
Or :
"The mechanism MUST allow Diameter clients to act during an overload situation in order to improve it while impacts are minimized"
They are OK for me, as they are in the line of my proposal: the client being aware of the overload situation, can act accordingly. Your proposals are more accurate, as indicating client actions.

But the last proposal on the table is the one proposed by Lionel aimed to have a compromise :
 "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition"

Nigel and I were accepting the Lionel's proposal to find a compromise but nevertheless I prefer your writing and support your proposals that could also be a compromise.

As a conclusion, I think we are in line, and I support your proposals with the objective to find a compromise.

Best regards

JJacques

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mercredi 13 mars 2013 09:36
À : Eric McMurry; [email-masked]; [email-masked]
Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hello all,

REQ-35:

REQ-35 (proposal):

REQ-35 (new proposal):

REQ-2 complement:

Proposal now is: 

Best regards
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric McMurry
Sent: martes, 12 de marzo de 2013 22:42
To: [email-masked]
Cc: DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry); BERRY, Nigel (Nigel)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Eric

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 13 Mar 2013 09:58:08 +0000

WRT REQ2, this poor dog has been beaten too badly, let's just leave it allow :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, March 13, 2013 5:35 AM
To: Maria Cruz Bartolome; Eric McMurry; [email-masked]; [email-masked]
Cc: DRAGE, Keith (Keith); Bessis, Thierry (Thierry); BERRY, Nigel (Nigel)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

HI Maria Cruz

========

For REQ2 

About your two proposals

Best regards

JJacques

-----Message d'origine-----

Hello all,

REQ-35:

REQ-35 (proposal):

REQ-35 (new proposal):

REQ-2 complement:

Proposal now is: 

Best regards
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric McMurry
Sent: martes, 12 de marzo de 2013 22:42
To: [email-masked]
Cc: DRAGE, Keith (Keith); [email-masked]; Bessis, Thierry (Thierry); BERRY, Nigel (Nigel)
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Eric

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Mar 2013 08:36:43 -0400

Hi, Comments inline:

> In fact it groups the two sentences with a MUST, so it is OK for me.

I had expected the requirement to work with or without agents would be a new, separate requirement. I think that, while it's related to the need to cross non-supporting agents, it's also distinct in the fact that it requires the solution to work in a pure client-server deployment as well. I prefer the separation, but could live with it if people want to combine them.

> You mentioned the REQ16 which I also agree.

Req16 does not necessarily imply the ability to cross non-supporting agents. It could, for example, be interpreted to mean that non-supporting clients are allowed in parallel with supporting clients. I would not depend on 16 by itself to get the point across. 

> As a conclusion, I think we are in line, and I support your proposals with the objective to find a compromise.

I am fine with either wording. In the interests of not beating Martin's dog (see Martin's email), it's probably easier to stick with Lionel's proposed wording, but I will not object if the consensus is to change to Maria's.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Mar 2013 08:40:59 -0400

Comment inline. (I commented on the other items in response to Jean-Jacques.

>            countermeasures against, malicious nodes.

I think Eric's concern is distinct from 30. It was not so much a general security requirement as an observation that crossing non-supporting nodes has the potential for security problems when you don't have an end-to-end mechanism to authenticate the overload report. A single report can effectively shut down a network, so it's important that you don't accept malicious ones. 

I think the details of that would be better handled as part of the solution engineering exercise than in requirements. The other general requirements to effect of "don't make things worse" should cover it :-)

---

From: Eric McMurry <[email-masked]>
Date: Wed, 13 Mar 2013 23:45:23 +0100

Hi Maria,

Comments inline.

Thanks,

Eric

> I think latest proposals are:

I think Ben and JJacques have covered this.  This is the first instance I have seen of combining the new agent/no-agent language with 35 and they don't really go together.  They should remain separate.

> But I presume it does not harm to be explicit here, like in former requirement.

I agree with Ben that this does not imply what you are reading into it.  Another requirement would be needed to make that clear.

[...]

> REQ-2 complement:

I agree with Martin about the dog, but this is also saying something different than the last proposal.  There are some areas where the requirements are justifiably intentionally a bit vague, to gove some roome to the mechanism designers where there are multiple ways to solve problems.  This is one of those cases.  The proposal here is too specific and does not reflect some of the discussion leading up to this point, namely the parts about overload being handled closer to the server as appropriate.

[...]

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 14 Mar 2013 09:25:24 -0400

WRT "gracefully" in Req 2. I thought we agreed to incorporate a reference 
to REQ 3, e.g., "gracefully (in accordance with Req 3)"

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   Ben Campbell <[email-masked]>
To:     "TROTTIN,       JEAN-JACQUES (JEAN-JACQUES)" 
<[email-masked]>
Cc:     "BERRY, Nigel \(Nigel\)" <[email-masked]>, "DRAGE, 
Keith \(Keith\)" <[email-masked]>, "Bessis,     Thierry 
\(Thierry\)" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:   03/13/2013 08:37 AM
Subject:        Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
Sent by:        [email-masked]

Hi, Comments inline:

On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
<[email-masked]> wrote:

> About REQ 35, my understanding was that the existing REQ35 wording was 
kept (with still the pending point between MUST and SHOULD as mentioned in 
a Nigel's mail), and that a new sentence "The solution MUST work in the 
presence or absence of Diameter agents between Diameter clients and 
servers" would be added. 
> You propose for REQ35 "The solution MUST work in the presence or absence 
of Diameter agents between Diameter clients and servers, regardless 
whether or not Diameter agents support the overload control mechanism". 
> In fact it groups the two sentences with a MUST, so it is OK for me.

I had expected the requirement to work with or without agents would be a 
new, separate requirement. I think that, while it's related to the need to 
cross non-supporting agents, it's also distinct in the fact that it 
requires the solution to work in a pure client-server deployment as well. 
I prefer the separation, but could live with it if people want to combine 
them.

> You mentioned the REQ16 which I also agree.

Req16 does not necessarily imply the ability to cross non-supporting 
agents. It could, for example, be interpreted to mean that non-supporting 
clients are allowed in parallel with supporting clients. I would not 
depend on 16 by itself to get the point across. 

> "The mechanism MUST allow Diameter clients to act during an overload 
situation in order to improve it while impacts are minimized"
> They are OK for me, as they are in the line of my proposal: the client 
being aware of the overload situation, can act accordingly. Your proposals 
are more accurate, as indicating client actions.
> "Diameter clients must be able to use the received load and overload 
information to support graceful behavior during an overload condition"
> 
> Nigel and I were accepting the Lionel's proposal to find a compromise 
but nevertheless I prefer your writing and support your proposals that 
could also be a compromise.
> As a conclusion, I think we are in line, and I support your proposals 
with the objective to find a compromise.

I am fine with either wording. In the interests of not beating Martin's 
dog (see Martin's email), it's probably easier to stick with Lionel's 
proposed wording, but I will not object if the consensus is to change to 
Maria's.

> "The solution MUST work in the presence or absence of Diameter agents 
between Diameter clients and servers, regardless whether or not Diameter 
agents support the overload control mechanism"
> About the comment by Eric on security (just mail below), we need to 
check then whether REQ-30 need to be modified, or a new requirement shall 
apply, right?
> First, I could accept the proposal we got now on the table, I do not 
want to keep discussion forever, but... I'd like to propose some 
enhancements that I think cover all people concerns stated so far, 
hopefully without rasing disagreements.
> 
> Proposal now is: 
> "Diameter clients must be able to use the received load and overload 
information to support graceful behavior during an overload condition"
> I think it is better to request that is "the mechanism" the one that 
should provide the means for the client to be able to do something, since 
we are specifying what the mechanism shall do in other requirements, like:
> Where I think "graceful behavior" is raising some concerns, in facts 
this is not specific enough in my opinion. Good requirement writing would 
avoid multiple interpretations. Then, what about this:
> "The mechanism MUST allow Diameter clients to act during an overload 
situation in order to improve it while impacts are minimized"
> I have stated before that I am fine with a MUST provided that the 
requirement for end to end security is also added.  Traversing 
non-supporint elements without this would be folly
> 
> I believe the best compromise here is to leave it as is, so that more 
thought can be put into this without constraining the solution to 
something that may be nearly impossible to deploy.  It may also be 
possible to define the security requirement for specific scenarios where 
the risk is higher.  This would include a specific requirement (at MUST 
level) stating that e2e security is required for traversing non-supporting 
elements.  I believe that this approach is generally consistent with what 
some have been discussing about using a MUST level on 35 along with 
constraints.
>>> With the clarification that the "SHOULD" is strong recommendation for 
solution designers i.e. if you can meet this requirement, your solution 
will have greater chances to be selected than a solution without, is it 
acceptable to keep the "SHOULD" in the draft?
>>> 
>>> OK or NOK?
>>> 
>> 
>> OK.
>> 
>> I would also accept a MUST, with the understanding that there may be 
limitations on what a non-supporting intermediary can do and still be 
traversable.
>> [Nigel] Ben, I am not sure which Requirement you are referring to but 
the solution has to work with and without Diameter Agents (stateful or not 
stateful) involved so any requirement should not disallow these scenarios.
>> 
>> [LM] this requirement was agreed: "The solution MUST work in the 
presence or absence of Diameter agents between Diameter clients and 
servers"
>>> Honestly, I don't understand why we have to go down each time to the 
solution space to understand a requirement!
>> My solution examples were intended to illustrate that there can be more 
than one solution approach, and we should be careful not to over-constrain 
the solution in the requirements. I did not mean for any of them to be 
assumed as the "real" solution.
>> [Nigel] I agree with Ben we have to dip our toe in the water of 
potential solutions that deal with all scenarios in order to understand 
the correct wording of requirements.
>>> "Diameter clients must be able to use the received load and overload 
information to support graceful behavior during an overload condition"
>> Grudgingly OK, with the provision that this allows but does not require 
the information to be sent end-to-end from server to client.
>> 
>> I would be _considerably_ happier with something of the form of "The 
solution must support graceful client behavior during an overload 
condition."
>> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use 
the received load and overload information to support graceful behavior 
during an overload condition" providing a necessary consequence of 
graceful behaviour may involve drastic load shedding at the client or the 
active proxy.
>> 
>> 
>>> 
>>> 2/ REQ 35:
>>> With the clarification that the "SHOULD" is strong recommendation for 
solution designers i.e. if you can meet this requirement, your solution 
will have greater chances to be selected than a solution without, is it 
acceptable to keep the "SHOULD" in the draft?
>>> 
>>> OK or NOK?
>>> 
>> 
>> OK.
>> 
>> I would also accept a MUST, with the understanding that there may be 
limitations on what a non-supporting intermediary can do and still be 
traversable.
>> [Nigel] Ben, I am not sure which Requirement you are referring to but 
the solution has to work with and without Diameter Agents (stateful or not 
stateful) involved so any requirement should not disallow these scenarios.
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
que les pieces jointes. Les messages electroniques etant susceptibles 
d'alteration, France Telecom - Orange decline toute responsabilite si ce 
message a ete altere, deforme ou falsifie. Merci.
>> privileged information that may be protected by law; they should not be 
distributed, used or copied without authorisation.
>> As emails may be altered, France Telecom - Orange is not liable for 
messages that have been modified, changed or falsified.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 14 Mar 2013 09:33:16 -0400

This was the proposal in the meeting.  I don't believe that Eric was participate and, as such, would not have known.

Steve

On Mar 14, 2013, at 9:25 AM, Janet P Gunn wrote:

> WRT "gracefully" in Req 2. I thought we agreed to incorporate a reference to REQ 3, e.g., "gracefully (in accordance with Req 3)" 
> 
> Janet
> 
> This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 
> 
> 
> 
> To:        "TROTTIN,        JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> 
> Cc:        "BERRY, Nigel \(Nigel\)" <[email-masked]>, "DRAGE,        Keith \(Keith\)" <[email-masked]>, "Bessis,        Thierry \(Thierry\)" <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Mar 2013 09:34:58 -0400

Yes, we did. My email was from before that discussion :-)

Thanks!

Ben.

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 14:24:37 +0000

WFM

De : [email-masked] [mailto:[email-masked]] De la part de Janet P Gunn
Envoyé : jeudi 14 mars 2013 14:25
À : Ben Campbell
Cc : [email-masked]; BERRY, Nigel (Nigel); DRAGE, Keith (Keith); Bessis, Thierry (Thierry); [email-masked]
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Janet

Hi, Comments inline:

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Fri, 15 Mar 2013 04:06:40 +0000

Hello all,

To REQ 35, I agree the new proposal could be a separate requirement.

To REQ 2, since there was too much discussion on it, I'm not going to trigger off another round again if all people can live with the compromise proposal from either Lionel or Maria Cruz, even both of which still seem vague to me. But we may have to keep in mind one point: To the client, the difference of the overload information of the servers from the one of the agent is that if the client knows the servers are overloaded, it might start to shed messages and mitigate the overload of the servers from the beginning, i.e. the originator of the request messages; While if the client only knows that the agent(s) is overloaded, it may decide to continue to route the messages to the servers via another agent or agent group. In the latter case, the client cannot contribute much to help the servers recover from overloaded situation.

Best Regards,
Susan

-----邮件原件-----
发件人: Eric McMurry [mailto:[email-masked]] 
发送时间: 2013年3月14日 6:45
收件人: Maria Cruz Bartolome
抄送: DRAGE, Keith (Keith); [email-masked]; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
主题: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Maria,

Comments inline.

Thanks,

Eric

[...]

[...]

---

From: Thierry Bessis <[email-masked]>
Date: Fri, 15 Mar 2013 12:13:20 +0100

Susan,

I believe you have a very good point, that just tend to show the issues
that we will face during the next phase, and also explain why we spent
so much time in discussions: What we really need is a mechanism to allow
a Diameter server to inform its Diameter clients of its load situation,
so that the client can take action (optimal distribution, shedding ...).
But we have requirements that at many places suggest that this is a hop
to hop mechanism. With a hop to hop protocol, the client only sees the
situation from the DA's reporting so the DA will need to combine its own
load situation with the one from each of the servers it talks to. Of
course it's complicated and will only work if all the DAs are upgraded
and behaving correctly, which would also probably violate some of the
requirements. My take on that is that given the way requirements are
written, two mechanisms will be needed: connection based hop to hop and
session based end to end.

Cordially,

Thierry

-- 
Thierry's signature

**

*--
Cordially,
Thierry Bessis*

ACS / IMS Solution Architect - ALTA Member - SARB Review Leader
Organization: ALU > S3G > ACS > IMS Sol Arch

N1 146.5Alcatel-Lucent France Lieu Dit Le Mail
44708 ORVAULT France
Tel/Fax: +1 630 979 7989 or +33 2 5178 3623
Corporate IM: tbessis

Engage: https://engage.alcatel-lucent.com/people/tbessis
ALTA Hot Line: http://alta.all.alcatel-lucent.com/hotline
SARB Site:
http://all.alcatel-lucent.com/wps/portal/cf/research/network_tech_strat/sarb
Every other Friday: An IMS product/component presentation. We'll cover
them all ! Please register:
https://engage.alcatel-lucent.com/groups/public-portal-for-the-ims-solution-architecture-board

Conference information:
2801 2801 (US):+1 800 771 8734 - (F):+33 800 941 674 - Access Code: 9797989
others countries see: https://engage.alcatel-lucent.com/docs/DOC-46568

*Upcoming planned Trips and Vacations: None*