Eric

On Feb 4, 2013, at 23:13 , Andrew = Booth <abooth@pt.com> = wrote:

Some minor = questions and comments on various requirements.

REQ 7: = I'm not sure that "the system remains stable" adds much on its own, = removing it doesn't seem to lose much:
= ALT REQ 7: The overload control mechanism and any = associated
= default algorithm(s) = MUST ensure that when the
= offered load drops from = above the overall
= capacity of the network = to below the overall
= capacity, the throughput = MUST stabilize and become
= equal to the offered = load. Note that this also
= requires that the = mechanism MUST allow nodes to
= shed load without = introducing oscillations.

The = text after the first sentence was intended to elaborate on it. It = would probably read about the same either way, but I don't think it = detracts having it there.

REQ 7: = query: Does this requirement imply that the proposed mechanism must = define one or more options for shedding load (as opposed to simply = requesting the clients to slow down)? Is it accurate to say that = processing TLS to get at the Diameter message may be a substantial part = of the message processing time, so a node may have limited ability to = distinguish between Diameter messages when shedding load? This = query applies to REQ 22 = also.

I don't think = this requirement implies that there be multiple algorithms, but that is = called out elsewhere (at least the ability to add = them).

Impact of TLS is rather implementation = dependent. I'm not sure what we could say about that here (or that = we should)

REQ 9: = Is this simpler/clearer? Or did I miss some cross = references?
= ALT REQ 9: The mechanism MUST function across fully = loaded as well as
= quiescent transport = connections. This is partially derived
= from REQ 7 above.

makes sense. good = catch.

REQ 13: = consider adding "The mechanism SHOULD NOT introduce substantial = additional work for nodes that are not in overload; in particular it = should not cause nodes to become overloaded".

not causing other nodes to = be come overloaded is covered in req 12 and 23. No introducing = substantial work when not overloaded is probably a subset of what is = there. I think that was in an earlier version of the draft and was = considered redundant. Perhaps others remember that = better.

REQ 20: = does "actual overload" deserve more clarification? For example, = would any or all of the following would represent "actual overload": CPU = usage, a deep send queue, messages incoming at an unexpectedly high = rate? Or is this something that would be defined by the proposed = mechanism? Or have I misunderstood completely?

the word actual may not = actually add anything here. All of the things you mentioned could = be causes of overload. I think the intent though is that existing = Diameter errors not be overloaded to be used for overload. Any = overload control mechanism needs to be clear about what is being = communicated.

REQ 21: = Does this imply that a node must be able to deduce overload of a peer or = indirectly accessible node based on local metrics only (response time, = send queue depth, etc)? Since "The mechanism MUST properly = function in these cases", does that require that explicit messaging is = unnecessary?

perhaps "properly = function" should be stated differently. The intent here is that = the mechanism not break things in this case and that the overload is = handled at least as well as it would have been were the overload control = signaling intact. The language in req 17 is close to this point I = think. How about we barrow that = language?

REQ 21: In cases where a = network node fails, is so overloaded that

= it cannot process messages, or cannot communicate = due to a

network = failure, it may not be able to provide explicit

= indications of the nature of the failure or = its levels of

= congestion. The mechanism MUST result

= in at least as much useful throughput as = would have resulted

= if the overload control signaling were = present.

This may imply = the actions you mention, as so other requirements around functioning in = environments with nodes that do, and do not support the mechanism, and = fairness in that case. Overload can be mitigated somewhat without = overload control signaling, but that is not sufficient to handle issues = that are occurring on networks now. A good bit of the front matter = in the draft discusses this point.

REQ 29: = query: why do we need to know who sent the overload info (note that the = security concerns are addressed in other requirements)? Do we lose = anything by removing the first sentence?
= ALT REQ 29: The mechanism MUST allow a node to = distinguish between
= overload at a next-hop = peer from overload at a node upstream
= of the peer. For = example, in Figure 5, the client must not
= mistake overload at = server 1 for overload at the agent,
= whether or not the agent = supports the mechanism.
REQ 29: = nit: why the cross reference to REQ 4?

I agree with this and = would go further. Upon reading this again, I don't think req 29 is = adding anything. Perhaps we should just add this example to 33 and = remove 29.

REQ = 33: "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.": = this wording seems to imply that the mechanism must support overload = specification of arbitrary granularity, with a corresponding increase in = the complexity required on implementations. Even supporting = "Diameter session" could force a node to maintain session state when it = is otherwise not required (more an issue for Agents than end nodes), at = a corresponding increase in the cost and complexity of that node. = Is there anything to be concerned about here? Or is REQ 13 = sufficient to limit = complexity?

I = think req 13 probably covers this. I understand your concern = though, and share it. There is potential for significant = complexity. There have been a lot of comments on this point and I = think there will be a fair amount of thinking going into appropriate = scoping of overload control information in ways that balance work = imposed on nodes with capacity left on the table. Perhaps adding the = word "unreasonably" in between "without" and "forcing" would make folks = feel more comfortable that the necessary wiggle room is here for the = mechanism specifiers.

REQ 35: query: explicitly mention that end-to-end = security is required here? Or is it not?

REQ 35: query: does this pretty much rule out = strictly a hop-by-hop = approach?

Jouni = answered these last two and that looked reasonable to = me.

Thanks,
Andrew

= --Apple-Mail=_1B907B82-C8DD-4FC8-ACFB-8A71D480927C-- From emcmurry@computer.org Sat Feb 16 11:31:28 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB97421F89E5 for ; Sat, 16 Feb 2013 11:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBdn3wE7ofTD for ; Sat, 16 Feb 2013 11:31:28 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 51B9221F89DC for ; Sat, 16 Feb 2013 11:31:28 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U6nTr-0002eM-Rc; Sat, 16 Feb 2013 19:31:27 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 69BC01E1FAC7; Sat, 16 Feb 2013 13:31:26 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/MjxAgf02ZYtLO0fPJvbgCouwt2YBoJ8A= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mljlSETwDco5; Sat, 16 Feb 2013 13:31:26 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 4FA711E1FAC1; Sat, 16 Feb 2013 13:31:26 -0600 (CST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: <93EA4687-35BC-4BF8-A61B-58EC72839D9E@nostrum.com> Date: Sat, 16 Feb 2013 13:31:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <93EA4687-35BC-4BF8-A61B-58EC72839D9E@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 19:31:29 -0000 I still favor removing the emergency services example entirely to avoid = confusion, but this language is okay with me if folks are happy with it. Thanks, Eric On Feb 8, 2013, at 16:53 , Ben Campbell wrote: >=20 >=20 > On Feb 7, 2013, at 1:11 PM, "THIEBAUT, LAURENT (LAURENT)" = wrote: >=20 >> 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.=20 >>=20 >>=20 >=20 > Hi, >=20 > I think one possible issue here is the assumption that emergency = sessions priority is always true is incorrect. There may well be uses of = diameter that do not have such requirements. Most uses in a _telecom_ = environment will. How about something like the following:=20 >=20 > "... For example, it may be more beneficial to process messages for = existing sessions ahead of new sessions. Some networks may have a = requirement to give priority to requests associated with emergency = sessions. ..." >=20 >=20 From emcmurry@computer.org Sat Feb 16 11:46:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986121F8700 for ; Sat, 16 Feb 2013 11:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKhPz1RVkgvW for ; Sat, 16 Feb 2013 11:46:45 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 61F8521F86BB for ; Sat, 16 Feb 2013 11:46:45 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U6nie-000AB5-Pr; Sat, 16 Feb 2013 19:46:45 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 0EBD01E20628; Sat, 16 Feb 2013 13:46:43 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX190wAYXL8cndHXHsr0vrIibWB826Vrxqv4= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ0iyYl20PHp; Sat, 16 Feb 2013 13:46:42 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id B81941E20617; Sat, 16 Feb 2013 13:46:42 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_47B658BF-7F48-44F4-A5C2-B382AE4B008A" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: Date: Sat, 16 Feb 2013 13:46:42 -0600 Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 19:46:46 -0000 --Apple-Mail=_47B658BF-7F48-44F4-A5C2-B382AE4B008A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi JJacques, I'm not sure this is the same thing that Laurent was saying. My = impression of his comments (which may be incorrect) was what he was = talking about within a single node. His requirement was that the = mechanism provide information up to whatever the real application of = that node is and allow it to exert control over the overload control = signaling. For example (apologies to those not familiar with 3GPP = terminology), an MME communicating with and HSS, where both support = overload control, would need to coordinate overload related actions for = that Diameter interface along with it's non-Diameter interfaces (such as = towards eNodeBs or serving gateways). To do that, the higher level = application functions of an MME need to have access to Diameter overload = information and the ability to influence Diameter overload control for = that interface to the HSS. Is this the gist of what you were getting = at, Laurent? I think what you are saying here is more that intermediate elements = should not have the ability to alter overload control signaling for = information that is scoped to elements on either side of them. Is that = right? thanks, Eric On Feb 11, 2013, at 1:43 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > =20 > Hi Eric > =20 > 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 would not propagate the = overload information upstream. > =20 > I don=92t say that it is systematic and in 3GPP it will depend of the = application case, it is why we write =93must allow=94. > =20 > =20 > Best regards > =20 > JJacques > =20 > =20 > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of THIEBAUT, LAURENT (LAURENT) > Sent: jeudi 7 f=E9vrier 2013 20:11 > To: Eric McMurry > Cc: dime@ietf.org > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > =20 > =20 > =20 > Hello Eric > Thanks for your feedback > =20 > 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) > =20 > 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.=20 > =20 > 3) As long as it is agreed/understood by the Dime group that =93the = possibility of passing overload information via intermediate agents that = do not support the extension=94 is required, I am fine. > =20 > Best Regards > Laurent=20 > ALCATEL-LUCENT > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_47B658BF-7F48-44F4-A5C2-B382AE4B008A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = JJacques,

I'm not sure this is the same thing that = Laurent was saying. My impression of his comments (which may be = incorrect) was what he was talking about within a single node. His = requirement was that the mechanism provide information up to whatever = the real application of that node is and allow it to exert control over = the overload control signaling. For example (apologies to those = not familiar with 3GPP terminology), an MME communicating with and HSS, = where both support overload control, would need to coordinate overload = related actions for that Diameter interface along with it's non-Diameter = interfaces (such as towards eNodeBs or serving gateways). To do = that, the higher level application functions of an MME need to have = access to Diameter overload information and the ability to influence = Diameter overload control for that interface to the HSS. Is this = the gist of what you were getting at, = Laurent?

I think what you are saying here is = more that intermediate elements should not have the ability to alter = overload control signaling for information that is scoped to elements on = either side of them. Is that = right?

thanks,

Eric

On Feb 11, 2013, at 1:43 , "TROTTIN, = JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trott= in@ALCATEL-LUCENT.COM> wrote:

Hi = Eric

About the = REQ2 with the addition of : The = mechanism MUST allow Diameter applications 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 would not propagate the overload = information upstream.

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

Best = regards

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of THIEBAUT, LAURENT = (LAURENT)
Sent: jeudi 7 f=E9vrier 2013 = 20:11
To: Eric= McMurry
Cc: dime@ietf.org
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 =93the possibility of passing overload information via = intermediate agents that do not support the extension=94 is required, I = am fine.

Best Regards
Laurent
ALCATEL-LUCENT
_______________________________________= ________
DiME mailing list
>> (Diameter Agents) in between. This might be a useful configuration = to >>> keep in mind for instance if the proposed mechanism recommends = (directly >>> or indirectly) some kind of retransmission logic e.g. if a node = sheds >>> work by returning DIAMETER_UNABLE_TO_DELIVER, then Agents on the = request >>> path could retransmit on another path, potentially multiplying the >>> number of messages that must be processed. >>>=20 >>> This might be an unusual configuration in Diameter, but it is simple = may >>> demonstrate issues that could exist when more and larger networks = are >>> hooked together. >>=20 >> Multiple agents have certainly been in the thinking. The thinking on = the >> single agent scenarios show in the draft was that the issues they = brought >> up would cover more complicated topologies in general, as I recall. = That >> said, there are some very complex topologies possible that make = overload >> control rather tricky, as you have pointed out. If there are missing >> requirements for these scenarios, then lets go over them and get them >> covered. >=20 > Ok. Is it worth including something like the following as an > informational comment? Possibly towards the end of 4.2 or as a 4.2.1?=20= > It's a little longer than I'd like, but it's a quick read. >=20 >=20 > In some network configurations, the retry mechanisms built in to the = base > Diameter protocol can cause message amplification when a node fails, = with > the possibility of propagating an overload condition to other nodes. > Consider for example the scenario in [RFC6733] section 7, Figure 7, > reproduced here as Figure X. >=20 > 1. Request +---------+ Link Broken > +-------------------------->|Diameter |----///----+ > | +---------------------| | v > +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+ > |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| > | | | Home | > | Relay 1 |--+ +---------+ | Server | > +---------+ | 3. Request |Diameter | +--------+ > +-------------------->| | ^ > | Relay 3 |-----------+ > +---------+ >=20 > Figure X: Example of Protocol Error Causing Message = Amplification >=20 > In the success path via Relay 3, Relay 1 generates 1 request and = receives > on answer. > If the request is instead sent via Relay 2, Relay 1 generates 2 = requests > and processes 1 error and 1 answer. > If the Diameter Home Server is unavailable via either path, Relay 1 > generates 2 requests and processes 2 errors. > If there were N intermediate relays connected to Relay 1 and the = Diameter > Home Server were unavailable, then Relay 1 could generate N requests = and > process N errors. >=20 > Resolving this issue is out of scope of the present work, though the > situation may be improved as a side effect of the overload mechanism. >=20 > A proposed overload handling mechanism should consider possible = message > amplification if it adds additional retransmissions, or if it uses > Diameter error codes that prompt automatic retransmissions. >=20 >=20 > Thoughts? I think this would happen only once (or a relatively small number of = times) for each failure. That is, Relay 1, when it receives the error = response from Relay 2 could decide not to send similar requests down = that path again. So, the next time Relay 1 receives a request that = would route to the Diameter Home Server, it could send it directly to = Relay 3. From emcmurry@computer.org Sat Feb 16 14:17:37 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D783921F899F; Sat, 16 Feb 2013 14:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85PxCRfagrSO; Sat, 16 Feb 2013 14:17:37 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id C98A121F85CC; Sat, 16 Feb 2013 14:17:33 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U6q4b-0007bc-8z; Sat, 16 Feb 2013 22:17:33 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 707DE1E27417; Sat, 16 Feb 2013 16:17:32 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Zj8np9FENjmtL3AzN9mtbkOotiFKHtr4= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxp0j24f5FoB; Sat, 16 Feb 2013 16:17:32 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 3CC081E27411; Sat, 16 Feb 2013 16:17:32 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: Date: Sat, 16 Feb 2013 16:02:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <55C0889B-2795-4806-A46D-7975BB8EAB2F@computer.org> References: <43587557-EA86-43A1-9F7E-C821FC6E35B6@gmail.com> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1499) Cc: dime-chairs@ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 22:17:38 -0000 There are several minor changes needed based on list discussions. There = are also a few open issues. An analysis of the requirements by 3GPP CT4 = is also in progress and comments may result from that. I've listed the = open and closed issues below. People involved in the discussions should = have a look to make sure I haven't missed something. I will update the draft with the comments that have been settled, and I = can wait a bit for open issues. We have until the 25th to submit this = for consideration in Orlando. Can the dime chairs please provide = guidance on the open issues and the upcoming CT4 review, considering = that WGLC has competed? Thanks, Eric ---Open Issues------------------ Req 2: request to add language requiring that Diameter applications be = allowed to be aware of overload situations. There seem to still be = multiple interpretations of what this means and it is not clear. = Discussion is needed. Req 21: clarification of "proper function" needed? new req wording = proposed. comments needed. Req 29: removing this is proposed. comments needed. Req 33: proposed wording change to clarify that infinite complexity not = be used. comments needed. Req 26: ongoing discussion on emergency services example. conclusion = needed. ---Agreed Changes---------------- Req 9: fix "above" reference Req 33: make extensibility for scopes MUST level Req 33: remove requirement for session scope Req xx: add explicit requirement for default algorithm On Feb 7, 2013, at 3:38 , Jouni Korhonen wrote: >=20 > Folks, >=20 > The WGLC for this I-D has completed. There was a fair amount of = comments and > I expect the authors to produce an update of the I-D. The sooner the = better > regarding the next steps in the publication process. There were few = comments > that seem to be still left open so those need to be hashes out first. = Just as=20 > a comment I am not too keen on adding new requirements at this point = unless > there is a wide support for one (wide means more than the individual = who > proposed it). >=20 > - Jouni >=20 >=20 >=20 > On Jan 22, 2013, at 2:29 PM, Jouni Korhonen = wrote: >=20 >> Folks, >>=20 >> The authors of draft-ietf-dime-overload-reqs have requested for a = WGLC >> and I think the document is stable enough for it. >>=20 >> This email starts a two week WGLC for = draft-ietf-dime-overload-reqs-03. >> The WGLC ends Tuesday 5th February 2013. Post your comments to the=20 >> mailing list and if you think something needs to be changed, put that >> also into the Issue Tracker.=20 >>=20 >> - Jouni & Lionel >>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Marco.Liebsch@neclab.eu Mon Feb 18 07:44:27 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4821F84FB for ; Mon, 18 Feb 2013 07:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew8iH4U064Ik for ; Mon, 18 Feb 2013 07:44:26 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 783A321F86CD for ; Mon, 18 Feb 2013 07:44:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DFCA910328C for ; Mon, 18 Feb 2013 16:44:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q84v825SZH2A for ; Mon, 18 Feb 2013 16:44:24 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C056B103270 for ; Mon, 18 Feb 2013 16:44:19 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 18 Feb 2013 16:44:01 +0100 From: Marco Liebsch To: "dime@ietf.org" Thread-Topic: Diameter overload vs. bulk signaling Thread-Index: Ac4N4kQnzIxWeTL/QE6iz4gjiPblfQ== Date: Mon, 18 Feb 2013 15:44:00 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551D1CB7@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D551D1CB7PALLENEofficehd_" MIME-Version: 1.0 Subject: [Dime] Diameter overload vs. bulk signaling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:44:27 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D551D1CB7PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, the DIME WG has a work item on bulk signaling, which is related to the over= load study in that it can help mitigating overload; mainly on the network paths = between diameter peers. The WG's solution document (http://tools.ietf.org/id/draft-ietf-dime-group-= signaling-00.txt) has expired and needs revision to reflect the WG's common view on how bulk = signaling and operations can be accomplished. Brief recap: At IETF84 we discussed two technical approaches to enable Diameter signalin= g for a group of sessions. These were using either dedicated Group Commands or a si= ngle Bulk Operations command, which carries the code of the Diameter command tha= t needs to be executed as group operation. Please see the slides from IETF84 for details (http://www.ietf.org/proceedings/84/slides/slides-84-dime-3.ppt= ) as well as the associated minutes (http://www.ietf.org/proceedings/84/minut= es/minutes-84-dime). A third approach came up during the meeting, which allows re-using existing Diameter messages and command codes. These messages carry additional AVPs to turn the existing Diameter command into a group command. A couple of technical details need to be considered and discussed here. My understanding at IETF84 was that the WG preferred adoption of the third approach, which allows re-use of existing messages. Please reply in particular if you think my understanding is wrong and you are in favor of any of the other approaches (or any new approach :-). Since we need to converge on a suitable approach and update the draft, let's make use of the ML to progress this work before IETF86, so we can take some decisions at IETF86 meeting. Maybe you have some comments already= , however, I'll start posting some technical points that I have in mind. Cheers, marco --_000_69756203DDDDE64E987BC4F70B71A26D551D1CB7PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

the DIME WG has a work item on bulk signaling, which is related to the over= load
study in that it can help mitigating overload; mainly on the network paths = between
diameter peers.

The WG's solution document (http://tools.ietf.or= g/id/draft-ietf-dime-group-signaling-00.txt)
has expired and needs revision to reflect the WG's common view on how bulk = signaling and

operations can be accomplished.

Brief recap:

At IETF84 we discussed two technical approaches t= o enable Diameter signaling for a
group of sessions. These were using either dedicated Group Commands or a si= ngle
Bulk Operations command, which carries the code of the Diameter command tha= t
needs to be executed as group operation. Please see the slides from IETF84<= br> for details (http://www.ietf.org/proceedings/84/slides/slides-84-dime-3.ppt= )
as well as the associated minutes (http://www.ietf.org/proceedings/84/minutes/m= inutes-84-dime).

A third approach came up during the meeting, whic= h allows re-using existing
Diameter messages and command codes. These messages carry additional
AVPs to turn the existing Diameter command into a group command. A couple of technical details need to be considered and discussed here.

My understanding at IETF84 was that the WG prefer= red adoption of the
third approach, which allows re-use of existing messages. Please reply
in particular if you think my understanding is wrong and you are in favor of any of the other approaches (or any new approach :-).

Since we need to converge on a suitable approach = and update the draft,
let's make use of the ML to progress this work before IETF86, so we can
take some decisions at IETF86 meeting. Maybe you have some comments already= ,
however, I'll start posting some technical points that I have in mind.

Cheers,

marco

--_000_69756203DDDDE64E987BC4F70B71A26D551D1CB7PALLENEofficehd_-- From Marco.Liebsch@neclab.eu Mon Feb 18 08:00:29 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A4121F8A45 for ; Mon, 18 Feb 2013 08:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4OXxJnZ+K7e for ; Mon, 18 Feb 2013 08:00:25 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BE66621F8BE4 for ; Mon, 18 Feb 2013 08:00:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3526710328B; Mon, 18 Feb 2013 17:00:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2lnVKr1r1fC; Mon, 18 Feb 2013 17:00:24 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 13F71103270; Mon, 18 Feb 2013 17:00:14 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 18 Feb 2013 16:59:55 +0100 From: Marco Liebsch To: Eric McMurry , "dime@ietf.org" Thread-Topic: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 Thread-Index: AQHN+Jw31fifwX/El0iiW9LuqejZt5huK7aAgA702QCAAsyb8A== Date: Mon, 18 Feb 2013 15:59:55 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551D1CE1@PALLENE.office.hd> References: <43587557-EA86-43A1-9F7E-C821FC6E35B6@gmail.com> <55C0889B-2795-4806-A46D-7975BB8EAB2F@computer.org> In-Reply-To: <55C0889B-2795-4806-A46D-7975BB8EAB2F@computer.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:00:29 -0000 Hi Eric, all, the DIME WG has a work item and associated draft on Diameter group signalin= g to reduce in particular load in the network caused by Diameter. I propose cross-referencing the two drafts, draft-ietf-dime-overload-reqs-03 and draft-ietf-dime-group-signaling. The overload requirements draft has a dedicated section 1.3 to clarify the difference between load on Diameter nodes and network load due to Diameter traffic. I think this is very important. What do you think about pointing to the complementary work item and draft about bulk signaling In Sec. 1.3? marco >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Er= ic >McMurry >Sent: Samstag, 16. Februar 2013 23:02 >To: dime@ietf.org >Cc: dime-chairs@ietf.org >Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 > >There are several minor changes needed based on list discussions. There a= re >also a few open issues. An analysis of the requirements by 3GPP CT4 is al= so in >progress and comments may result from that. I've listed the open and clos= ed >issues below. People involved in the discussions should have a look to ma= ke sure >I haven't missed something. > >I will update the draft with the comments that have been settled, and I ca= n wait >a bit for open issues. We have until the 25th to submit this for consider= ation in >Orlando. Can the dime chairs please provide guidance on the open issues a= nd >the upcoming CT4 review, considering that WGLC has competed? > >Thanks, > >Eric > >---Open Issues------------------ > >Req 2: request to add language requiring that Diameter applications be al= lowed >to be aware of overload situations. There seem to still be multiple >interpretations of what this means and it is not clear. Discussion is nee= ded. > >Req 21: clarification of "proper function" needed? new req wording propos= ed. >comments needed. > >Req 29: removing this is proposed. comments needed. > >Req 33: proposed wording change to clarify that infinite complexity not be= used. >comments needed. > >Req 26: ongoing discussion on emergency services example. conclusion need= ed. > > >---Agreed Changes---------------- > >Req 9: fix "above" reference > >Req 33: make extensibility for scopes MUST level > >Req 33: remove requirement for session scope > >Req xx: add explicit requirement for default algorithm > > > >On Feb 7, 2013, at 3:38 , Jouni Korhonen wrote: > >> >> Folks, >> >> The WGLC for this I-D has completed. There was a fair amount of >> comments and I expect the authors to produce an update of the I-D. The >> sooner the better regarding the next steps in the publication process. >> There were few comments that seem to be still left open so those need >> to be hashes out first. Just as a comment I am not too keen on adding >> new requirements at this point unless there is a wide support for one >> (wide means more than the individual who proposed it). >> >> - Jouni >> >> >> >> On Jan 22, 2013, at 2:29 PM, Jouni Korhonen >wrote: >> >>> Folks, >>> >>> The authors of draft-ietf-dime-overload-reqs have requested for a >>> WGLC and I think the document is stable enough for it. >>> >>> This email starts a two week WGLC for draft-ietf-dime-overload-reqs-03. >>> The WGLC ends Tuesday 5th February 2013. Post your comments to the >>> mailing list and if you think something needs to be changed, put that >>> also into the Issue Tracker. >>> >>> - Jouni & Lionel >>> >>> >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Mon Feb 18 08:01:56 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2036F21F86F7 for ; Mon, 18 Feb 2013 08:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPRTDfw8M515 for ; Mon, 18 Feb 2013 08:01:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AE12421F86C8 for ; Mon, 18 Feb 2013 08:01:54 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 40251324A3D; Mon, 18 Feb 2013 17:01:53 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1064F23806C; Mon, 18 Feb 2013 17:01:53 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 17:01:52 +0100 From: To: Marco Liebsch , "dime@ietf.org" Thread-Topic: Diameter overload vs. bulk signaling Thread-Index: Ac4N4kQnzIxWeTL/QE6iz4gjiPblfQADs07A Date: Mon, 18 Feb 2013 16:01:52 +0000 Message-ID: <17246_1361203313_51225071_17246_4480_1_6B7134B31289DC4FAF731D844122B36E1123AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <69756203DDDDE64E987BC4F70B71A26D551D1CB7@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D551D1CB7@PALLENE.office.hd> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E1123ADPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.18.150318 Subject: Re: [Dime] Diameter overload vs. bulk signaling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:01:56 -0000 --_000_6B7134B31289DC4FAF731D844122B36E1123ADPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As an individual, I support the 3rd approach, reusing existing commands. Bu= t it is not a surprise as I was one of the defender of this approach during= the meeting. Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Mar= co Liebsch Envoy=E9 : lundi 18 f=E9vrier 2013 16:44 =C0 : dime@ietf.org Objet : [Dime] Diameter overload vs. bulk signaling Folks, the DIME WG has a work item on bulk signaling, which is related to the over= load study in that it can help mitigating overload; mainly on the network paths = between diameter peers. The WG's solution document (http://tools.ietf.org/id/draft-ietf-dime-group-= signaling-00.txt) has expired and needs revision to reflect the WG's common view on how bulk = signaling and operations can be accomplished. Brief recap: At IETF84 we discussed two technical approaches to enable Diameter signalin= g for a group of sessions. These were using either dedicated Group Commands or a si= ngle Bulk Operations command, which carries the code of the Diameter command that needs to be executed as group operation. Please see the slides from IETF84 for details (http://www.ietf.org/proceedings/84/slides/slides-84-dime-3.ppt) as well as the associated minutes (http://www.ietf.org/proceedings/84/minut= es/minutes-84-dime). A third approach came up during the meeting, which allows re-using existing Diameter messages and command codes. These messages carry additional AVPs to turn the existing Diameter command into a group command. A couple of technical details need to be considered and discussed here. My understanding at IETF84 was that the WG preferred adoption of the third approach, which allows re-use of existing messages. Please reply in particular if you think my understanding is wrong and you are in favor of any of the other approaches (or any new approach :-). Since we need to converge on a suitable approach and update the draft, let's make use of the ML to progress this work before IETF86, so we can take some decisions at IETF86 meeting. Maybe you have some comments already, however, I'll start posting some technical points that I have in mind. Cheers, marco ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E1123ADPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

As an i= ndividual, I support the 3^rd approach, reusing existing commands= . But it is not a surprise as I was one of the defender of this approach du= ring the meeting.

&n= bsp;

Regards= ,

&n= bsp;

Lionel<= o:p>

&n= bsp;

De : dime= -bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Marco Liebsch
Envoy=E9 : lundi 18 f=E9vrier 2013 16:44
=C0 : dime@ietf.org
Objet : [Dime] Diameter overload vs. bulk signaling<= /span>

Folks,

the DIME WG has a work item on bulk signaling, which is related to the over= load
study in that it can help mitigating overload; mainly on the network paths = between
diameter peers.

The WG's solution document (= http://tools.ietf.org/id/draft-ietf-dime-group-signaling-00.txt)
has expired and needs revision to reflect the WG's common view on how bulk = signaling and

operations can be accomplish= ed.

Brief recap:

At IETF84 we discussed two technical approaches to enable Diameter signa= ling for a
group of sessions. These were using either dedicated Group Commands or a si= ngle
Bulk Operations command, which carries the code of the Diameter command tha= t
needs to be executed as group operation. Please see the slides from IETF84<= br> for details (http://www.ietf.org/proceedings/84/slides/slides-84-dime-3.ppt= )
as well as the associated minutes (http://www.ietf.org/proceedings/84/minutes/m= inutes-84-dime).

A third approach came up dur= ing the meeting, which allows re-using existing
Diameter messages and command codes. These messages carry additional
AVPs to turn the existing Diameter command into a group command. A couple of technical details need to be considered and discussed here.

My understanding at IETF84 w= as that the WG preferred adoption of the
third approach, which allows re-use of existing messages. Please reply
in particular if you think my understanding is wrong and you are in favor of any of the other approaches (or any new approach :-).<= /p>

Since we need to converge on= a suitable approach and update the draft,
let's make use of the ML to progress this work before IETF86, so we can
take some decisions at IETF86 meeting. Maybe you have some comments already= ,
however, I'll start posting some technical points that I have in mind.

Cheers,

marco

______________________________________________________________________= ___________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E1123ADPEXCVZYM13corpora_-- From emcmurry@computer.org Mon Feb 18 09:32:00 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980AB21F8C6C for ; Mon, 18 Feb 2013 09:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMJSQs9qdJDF for ; Mon, 18 Feb 2013 09:32:00 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id E5E4B21F8C66 for ; Mon, 18 Feb 2013 09:31:59 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U7UZL-000Ei9-7V; Mon, 18 Feb 2013 17:31:59 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id E8EAB1E981FE; Mon, 18 Feb 2013 11:31:57 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+zfDj/4NZ96lGNNyYbFvAwcJA5/a6fKzc= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_D4zJ1Ketu1; Mon, 18 Feb 2013 11:31:57 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id B52781E981F8; Mon, 18 Feb 2013 11:31:57 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D551D1CE1@PALLENE.office.hd> Date: Mon, 18 Feb 2013 11:31:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9A82E3F6-4367-49AC-A1EB-266C72DCDE59@computer.org> References: <43587557-EA86-43A1-9F7E-C821FC6E35B6@gmail.com> <55C0889B-2795-4806-A46D-7975BB8EAB2F@computer.org> <69756203DDDDE64E987BC4F70B71A26D551D1CE1@PALLENE.office.hd> To: Marco Liebsch X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:32:00 -0000 Hi Marco, Thanks for the suggestion. I could see overload control mechanisms = possibly leveraging (and referencing) this work, for example with group = oriented scoping of overload information. The requirements are not referencing any mechanisms though. They are = intended to place as few constraints on the designers of overload = control mechanisms as possible, so we avoided that. Thanks, Eric On Feb 18, 2013, at 9:59 , Marco Liebsch = wrote: > Hi Eric, all, >=20 > the DIME WG has a work item and associated draft on Diameter group = signaling > to reduce in particular load in the network caused by Diameter. I = propose > cross-referencing the two drafts, draft-ietf-dime-overload-reqs-03 and > draft-ietf-dime-group-signaling. >=20 > The overload requirements draft has a dedicated section 1.3 to clarify = the > difference between load on Diameter nodes and network load due to > Diameter traffic. I think this is very important. What do you think = about > pointing to the complementary work item and draft about bulk signaling > In Sec. 1.3? >=20 > marco >=20 >=20 >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Eric >> McMurry >> Sent: Samstag, 16. Februar 2013 23:02 >> To: dime@ietf.org >> Cc: dime-chairs@ietf.org >> Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 >>=20 >> There are several minor changes needed based on list discussions. = There are >> also a few open issues. An analysis of the requirements by 3GPP CT4 = is also in >> progress and comments may result from that. I've listed the open and = closed >> issues below. People involved in the discussions should have a look = to make sure >> I haven't missed something. >>=20 >> I will update the draft with the comments that have been settled, and = I can wait >> a bit for open issues. We have until the 25th to submit this for = consideration in >> Orlando. Can the dime chairs please provide guidance on the open = issues and >> the upcoming CT4 review, considering that WGLC has competed? >>=20 >> Thanks, >>=20 >> Eric >>=20 >> ---Open Issues------------------ >>=20 >> Req 2: request to add language requiring that Diameter applications = be allowed >> to be aware of overload situations. There seem to still be multiple >> interpretations of what this means and it is not clear. Discussion = is needed. >>=20 >> Req 21: clarification of "proper function" needed? new req wording = proposed. >> comments needed. >>=20 >> Req 29: removing this is proposed. comments needed. >>=20 >> Req 33: proposed wording change to clarify that infinite complexity = not be used. >> comments needed. >>=20 >> Req 26: ongoing discussion on emergency services example. conclusion = needed. >>=20 >>=20 >> ---Agreed Changes---------------- >>=20 >> Req 9: fix "above" reference >>=20 >> Req 33: make extensibility for scopes MUST level >>=20 >> Req 33: remove requirement for session scope >>=20 >> Req xx: add explicit requirement for default algorithm >>=20 >>=20 >>=20 >> On Feb 7, 2013, at 3:38 , Jouni Korhonen = wrote: >>=20 >>>=20 >>> Folks, >>>=20 >>> The WGLC for this I-D has completed. There was a fair amount of >>> comments and I expect the authors to produce an update of the I-D. = The >>> sooner the better regarding the next steps in the publication = process. >>> There were few comments that seem to be still left open so those = need >>> to be hashes out first. Just as a comment I am not too keen on = adding >>> new requirements at this point unless there is a wide support for = one >>> (wide means more than the individual who proposed it). >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>> On Jan 22, 2013, at 2:29 PM, Jouni Korhonen >> wrote: >>>=20 >>>> Folks, >>>>=20 >>>> The authors of draft-ietf-dime-overload-reqs have requested for a >>>> WGLC and I think the document is stable enough for it. >>>>=20 >>>> This email starts a two week WGLC for = draft-ietf-dime-overload-reqs-03. >>>> The WGLC ends Tuesday 5th February 2013. Post your comments to the >>>> mailing list and if you think something needs to be changed, put = that >>>> also into the Issue Tracker. >>>>=20 >>>> - Jouni & Lionel >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Mon Feb 18 12:15:54 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF8F21F8CB3 for ; Mon, 18 Feb 2013 12:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJfZzC1fmSaJ for ; Mon, 18 Feb 2013 12:15:53 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEE021F8CB2 for ; Mon, 18 Feb 2013 12:15:53 -0800 (PST) Received: from [10.119.74.54] (prod02.s.dfw.fullmeshnetworks.com [174.34.135.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1IKFmB0020189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2013 14:15:49 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ben Campbell Date: Mon, 18 Feb 2013 14:15:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <59E7E136-056A-4E36-A209-73D3A1096F22@nostrum.com> References: <20130218201151.23785.66451.idtracker@ietfa.amsl.com> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 174.34.135.219 is authenticated by a trusted mechanism) Cc: "dime-chairs@tools.ietf.org" Subject: [Dime] Fwd: New Version Notification for draft-campbell-dime-overload-data-analysis-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:15:54 -0000 Hi, We've submitted a draft that compares the data elements between the two = existing Diameter overload mechanism drafts. We hope this draft will = help frame the discussion, so that we can create a transport-independent = data model for Diameter overload control. Feedback and discussion are encouraged. Thanks! Ben. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-campbell-dime-overload-data-analysis-00.txt > Date: February 18, 2013 2:11:51 PM CST > To: ben@nostrum.com > Cc: adam@nostrum.com, jouni.nospam@gmail.com, = hannes.tschofenig@nsn.com >=20 >=20 > A new version of I-D, = draft-campbell-dime-overload-data-analysis-00.txt > has been successfully submitted by Ben Campbell and posted to the > IETF repository. >=20 > Filename: draft-campbell-dime-overload-data-analysis > Revision: 00 > Title: Diameter Overload Data Analysis > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-campbell-dime-overload-data-anal= ysis-00.txt > Status: = http://datatracker.ietf.org/doc/draft-campbell-dime-overload-data-analysis= > Htmlized: = http://tools.ietf.org/html/draft-campbell-dime-overload-data-analysis-00 >=20 >=20 > Abstract: > When a Diameter server or agent becomes overloaded, it needs to be > able to gracefully reduce its load, typically by informing clients = to > reduce sending traffic for some period of time. Multiple mechanisms > have been proposed for transporting overload and load information. > While these proposals differ in many ways, they share similar data > requirements. This document analyzes the data requirements of each > proposal with a view towards proposing a common set of of Diameter > Attribute-Value Pairs (AVPs). >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From Marco.Liebsch@neclab.eu Tue Feb 19 00:35:35 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8202821F8802 for ; Tue, 19 Feb 2013 00:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZhqCEl1SrB3 for ; Tue, 19 Feb 2013 00:35:34 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8FED221F87EE for ; Tue, 19 Feb 2013 00:35:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 00CEB1032C4; Tue, 19 Feb 2013 09:35:34 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUwEkWEUuZ+D; Tue, 19 Feb 2013 09:35:33 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id DBFA31032C1; Tue, 19 Feb 2013 09:35:23 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 09:35:02 +0100 From: Marco Liebsch To: Eric McMurry Thread-Topic: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 Thread-Index: AQHN+Jw31fifwX/El0iiW9LuqejZt5huK7aAgA702QCAAsyb8IAADIwAgAEMLjA= Date: Tue, 19 Feb 2013 08:34:49 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551D41F3@PALLENE.office.hd> References: <43587557-EA86-43A1-9F7E-C821FC6E35B6@gmail.com> <55C0889B-2795-4806-A46D-7975BB8EAB2F@computer.org> <69756203DDDDE64E987BC4F70B71A26D551D1CE1@PALLENE.office.hd> <9A82E3F6-4367-49AC-A1EB-266C72DCDE59@computer.org> In-Reply-To: <9A82E3F6-4367-49AC-A1EB-266C72DCDE59@computer.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:35:35 -0000 Hi Eric, true, a pointer to a solution for group signaling may be misplaced in a requirements document. I just thought about a reference to the work that's being done in DIME, simply to not strictly scope out solving the net= work load issue in 3.1. But I got your point. Thanks, marco >-----Original Message----- >From: Eric McMurry [mailto:emcmurry@computer.org] >Sent: Montag, 18. Februar 2013 18:32 >To: Marco Liebsch >Cc: dime@ietf.org >Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 > >Hi Marco, > >Thanks for the suggestion. I could see overload control mechanisms possib= ly >leveraging (and referencing) this work, for example with group oriented sc= oping >of overload information. > >The requirements are not referencing any mechanisms though. They are >intended to place as few constraints on the designers of overload control >mechanisms as possible, so we avoided that. > >Thanks, > >Eric > > >On Feb 18, 2013, at 9:59 , Marco Liebsch wrote: > >> Hi Eric, all, >> >> the DIME WG has a work item and associated draft on Diameter group >> signaling to reduce in particular load in the network caused by >> Diameter. I propose cross-referencing the two drafts, >> draft-ietf-dime-overload-reqs-03 and draft-ietf-dime-group-signaling. >> >> The overload requirements draft has a dedicated section 1.3 to clarify >> the difference between load on Diameter nodes and network load due to >> Diameter traffic. I think this is very important. What do you think >> about pointing to the complementary work item and draft about bulk >> signaling In Sec. 1.3? >> >> marco >> >> >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >>> Of Eric McMurry >>> Sent: Samstag, 16. Februar 2013 23:02 >>> To: dime@ietf.org >>> Cc: dime-chairs@ietf.org >>> Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 >>> >>> There are several minor changes needed based on list discussions. >>> There are also a few open issues. An analysis of the requirements by >>> 3GPP CT4 is also in progress and comments may result from that. I've >>> listed the open and closed issues below. People involved in the >>> discussions should have a look to make sure I haven't missed something. >>> >>> I will update the draft with the comments that have been settled, and >>> I can wait a bit for open issues. We have until the 25th to submit >>> this for consideration in Orlando. Can the dime chairs please >>> provide guidance on the open issues and the upcoming CT4 review, >considering that WGLC has competed? >>> >>> Thanks, >>> >>> Eric >>> >>> ---Open Issues------------------ >>> >>> Req 2: request to add language requiring that Diameter applications >>> be allowed to be aware of overload situations. There seem to still >>> be multiple interpretations of what this means and it is not clear. Di= scussion >is needed. >>> >>> Req 21: clarification of "proper function" needed? new req wording >proposed. >>> comments needed. >>> >>> Req 29: removing this is proposed. comments needed. >>> >>> Req 33: proposed wording change to clarify that infinite complexity not= be >used. >>> comments needed. >>> >>> Req 26: ongoing discussion on emergency services example. conclusion >needed. >>> >>> >>> ---Agreed Changes---------------- >>> >>> Req 9: fix "above" reference >>> >>> Req 33: make extensibility for scopes MUST level >>> >>> Req 33: remove requirement for session scope >>> >>> Req xx: add explicit requirement for default algorithm >>> >>> >>> >>> On Feb 7, 2013, at 3:38 , Jouni Korhonen wrote= : >>> >>>> >>>> Folks, >>>> >>>> The WGLC for this I-D has completed. There was a fair amount of >>>> comments and I expect the authors to produce an update of the I-D. >>>> The sooner the better regarding the next steps in the publication proc= ess. >>>> There were few comments that seem to be still left open so those >>>> need to be hashes out first. Just as a comment I am not too keen on >>>> adding new requirements at this point unless there is a wide support >>>> for one (wide means more than the individual who proposed it). >>>> >>>> - Jouni >>>> >>>> >>>> >>>> On Jan 22, 2013, at 2:29 PM, Jouni Korhonen >>> wrote: >>>> >>>>> Folks, >>>>> >>>>> The authors of draft-ietf-dime-overload-reqs have requested for a >>>>> WGLC and I think the document is stable enough for it. >>>>> >>>>> This email starts a two week WGLC for draft-ietf-dime-overload-reqs-0= 3. >>>>> The WGLC ends Tuesday 5th February 2013. Post your comments to the >>>>> mailing list and if you think something needs to be changed, put >>>>> that also into the Issue Tracker. >>>>> >>>>> - Jouni & Lionel >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime From Marco.Liebsch@neclab.eu Tue Feb 19 06:48:53 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9462421F8B6C for ; Tue, 19 Feb 2013 06:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4M2jnAjVQHt for ; Tue, 19 Feb 2013 06:48:52 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA621F8A74 for ; Tue, 19 Feb 2013 06:48:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CFA2C1032F5; Tue, 19 Feb 2013 15:48:51 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGg9PZEZfMTU; Tue, 19 Feb 2013 15:48:51 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B5E081032F7; Tue, 19 Feb 2013 15:48:41 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 15:48:41 +0100 From: Marco Liebsch To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: Diameter overload vs. bulk signaling Thread-Index: Ac4N4kQnzIxWeTL/QE6iz4gjiPblfQADs07AAC9dfPA= Date: Tue, 19 Feb 2013 14:48:29 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551D8524@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D551D1CB7@PALLENE.office.hd> <17246_1361203313_51225071_17246_4480_1_6B7134B31289DC4FAF731D844122B36E1123AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <17246_1361203313_51225071_17246_4480_1_6B7134B31289DC4FAF731D844122B36E1123AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Diameter overload vs. bulk signaling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:48:53 -0000 Lionel, yes, I remember your position and your input on technical details how to enable command re-use. I think from the previously discussed candidates, dedicated group commands was the cleanest approach, whereas the command re-use seems to be a low-effort but efficient approach. Fine with that, not the first time proto= cols, in particular Diameter, are tweaked to enable a certain operation. Most important here IMHO is that signaling is unambiguous and the group-enabled protocol remains backward compatible, just in case the receiver or proxy of a group command cannot process the command= . The sender needs to receive and correctly interpret a response which should result in a fallback to multiple individual commands. marco >-----Original Message----- >From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >Sent: Montag, 18. Februar 2013 17:02 >To: Marco Liebsch; dime@ietf.org >Subject: RE: Diameter overload vs. bulk signaling > >Hi, > > > >As an individual, I support the 3rd approach, reusing existing commands. B= ut it is >not a surprise as I was one of the defender of this approach during the me= eting. > > > >Regards, > > > >Lionel > > > >De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de >Marco Liebsch Envoy=E9 : lundi 18 f=E9vrier 2013 16:44 =C0 : dime@ietf.org= Objet : >[Dime] Diameter overload vs. bulk signaling > > > >Folks, > >the DIME WG has a work item on bulk signaling, which is related to the ove= rload >study in that it can help mitigating overload; mainly on the network paths >between diameter peers. > > > >The WG's solution document (http://tools.ietf.org/id/draft-ietf-dime-group= - >signaling-00.txt) >has expired and needs revision to reflect the WG's common view on how bulk >signaling and > >operations can be accomplished. > > > >Brief recap: > >At IETF84 we discussed two technical approaches to enable Diameter signali= ng >for a group of sessions. These were using either dedicated Group Commands = or >a single Bulk Operations command, which carries the code of the Diameter >command that needs to be executed as group operation. Please see the slide= s >from IETF84 for details (http://www.ietf.org/proceedings/84/slides/slides-= 84- >dime-3.ppt) >as well as the associated minutes >(http://www.ietf.org/proceedings/84/minutes/minutes-84-dime). > >A third approach came up during the meeting, which allows re-using existin= g >Diameter messages and command codes. These messages carry additional AVPs >to turn the existing Diameter command into a group command. A couple of >technical details need to be considered and discussed here. > > > >My understanding at IETF84 was that the WG preferred adoption of the third >approach, which allows re-use of existing messages. Please reply in partic= ular if >you think my understanding is wrong and you are in favor of any of the oth= er >approaches (or any new approach :-). > > > >Since we need to converge on a suitable approach and update the draft, let= 's >make use of the ML to progress this work before IETF86, so we can take som= e >decisions at IETF86 meeting. Maybe you have some comments already, >however, I'll start posting some technical points that I have in mind. > >Cheers, > >marco > > > > > > > >_________________________________________________________________ >________________________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, expl= oites ou >copies sans autorisation. Si vous avez recu ce message par erreur, veuille= z le >signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les m= essages >electroniques etant susceptibles d'alteration, France Telecom - Orange dec= line >toute responsabilite si ce message a ete altere, deforme ou falsifie. Merc= i. > >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 del= ete this >message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for messag= es >that have been modified, changed or falsified. >Thank you. From Marco.Liebsch@neclab.eu Tue Feb 19 07:20:47 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384F221F882D for ; Tue, 19 Feb 2013 07:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CONy6WX1uRIf for ; Tue, 19 Feb 2013 07:20:46 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7562821F880F for ; Tue, 19 Feb 2013 07:20:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D054B1032F7 for ; Tue, 19 Feb 2013 16:20:45 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJjm3NhC6si8 for ; Tue, 19 Feb 2013 16:20:45 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B4F491032F6 for ; Tue, 19 Feb 2013 16:20:40 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 16:20:40 +0100 From: Marco Liebsch To: "dime@ietf.org" Thread-Topic: Command re-use, M-bit of new group AVPs Thread-Index: Ac4OsUNUQpxH1ZzkTIG+jAOQXYHuCQ== Date: Tue, 19 Feb 2013 15:20:29 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551D855F@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] Command re-use, M-bit of new group AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:20:47 -0000 Hi, the latest proposal to enable Diameter to signal group commands re-uses existing Diameter messages and adds new group-specific AVPs to the command. Examples for new AVPs are a Group-Session-ID AVP and a Group-Session-Action= AVP. Let's dig into some technical details to assess the approach. IMO, the M-bit of the new AVPs must be set and must result in an error resp= onse at a receiver in case the receiver of the group command does not understand= the semantics of the new AVP, hence it does not support group operations. The s= ender of the group command must then fall back to signal individual commands for each session. The only way to *not* set the M-bit and 'ignore' the new group AVP at such receiver would be to include sufficient information according to the standard application, including a single session's Session ID. That could enable the receiver to process the command for at least one single session of the group. This would require adding a single session's Session-ID into the typically mandatory Session-ID AVP of = the message. The receiver may send a positive response to the sender of the group messag= e and indicate that solely for the included Session ID the command had been processed successfully. This assumes a standard Diameter peer behaves like = that. If that works, the sender could omit sending an individual command at least= for the session that had been processed already. Any comments? marco From Marco.Liebsch@neclab.eu Tue Feb 19 07:50:48 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECCF21F8B6C for ; Tue, 19 Feb 2013 07:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYF7ZameoJwT for ; Tue, 19 Feb 2013 07:50:47 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3AA21F882E for ; Tue, 19 Feb 2013 07:50:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 42FA61032FD for ; Tue, 19 Feb 2013 16:50:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xegp+fz5MfMf for ; Tue, 19 Feb 2013 16:50:46 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 279A01032FC for ; Tue, 19 Feb 2013 16:50:41 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 16:50:41 +0100 From: Marco Liebsch To: "dime@ietf.org" Thread-Topic: Command re-use, setting of Session-ID AVP Thread-Index: Ac4OtcLIuklXVXaaSdK4oRU9fuI7VQ== Date: Tue, 19 Feb 2013 15:50:29 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551D8596@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] Command re-use, setting of Session-ID AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:50:48 -0000 Hi, the latest proposal to enable Diameter to signal group commands re-uses exi= sting Diameter messages and adds new group-specific AVPs to the command. How to set the session's mandatory Session-ID? It has a fixed location in t= he message and message parsing may rely on the value of the Session-ID AVP as key to lookup a particular session's entry in the local database. Group-Session-ID AVP(s) may follow the mandatory Session-ID.=20 Now, the mandatory Session-ID AVP could hold the following values: + All-0 or any other not allocated value: Probably not conform to standard peers which do not support group operations + Group-Session-ID: Previously agreed with the peer. May conflict with the = original definition of the Session-ID to hold a single session's ID.=20 + Single Session ID of a session which is part of the previously assigned g= roup.=20 Would allow fallback to process the command for a single session only. Any comments? marco =20 From Marco.Liebsch@neclab.eu Tue Feb 19 08:24:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0916F21F8E0C for ; Tue, 19 Feb 2013 08:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr2yTq+bnbdY for ; Tue, 19 Feb 2013 08:24:44 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 648CF21F8E08 for ; Tue, 19 Feb 2013 08:24:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 70B7C1032FC for ; Tue, 19 Feb 2013 17:24:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QowGmkhm43Uj for ; Tue, 19 Feb 2013 17:24:40 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 54A841032E6 for ; Tue, 19 Feb 2013 17:24:35 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 17:24:03 +0100 From: Marco Liebsch To: "dime@ietf.org" Thread-Topic: Command re-use, implicit capability exchange Thread-Index: Ac4OuQyQ8H4ReiUWQhuKnixoZI/HFA== Date: Tue, 19 Feb 2013 16:24:03 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551D861C@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] Command re-use, implicit capability exchange X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:24:46 -0000 Hi, the latest proposal to enable Diameter to signal group commands re-uses exi= sting Diameter messages and adds new group-specific AVPs to the command. Can such approach implicitly avoid conflicts with group signaling between a= group-enabled Diameter node and a Diameter node, which does *not* support group signaling? When the spe= cification allows each node to assign a session to a group and both sides agree to the group,= it means implicitly that at least these two nodes support group operations. In such case, the new AVPs to assign a session to a group, could be informa= tional, hence they do not have the M-bit set. Group assignment could e.g. be done during AAR/AAA when= the session ID is built. In case a receive cannot understand the semantics of the AVPs that are mean= t to build the group, the response must not include these AVPs. The originator of the AAR implici= tly learns that the remote peer does not support group operations. In case the remote peer does= not want to assign the session to a group for other reasons, this needs to be signaled = explicitly. It's more difficult if group assignment is being done only by the receiver = of a message and the receiver indicates the group in the response (i.e. AAA). The sender= of the AAR may not be able to interpret the group-specific AVPs. Furthermore, changes in the support of group operations may be possible aft= er one of the Diameter nodes changed and the existing session context is transferred to t= he new Diameter node. That could be after a handover or after a failover scenario.= Here, group re-assignment is needed anyhow, at least in case of handover. First handsha= kes after such relocation of a Diameter node may require fallback to single session o= perations e.g. to assign a session to a new group. Any thoughts? marco From lists.abooth@gmail.com Wed Feb 20 11:29:55 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17901F0D05 for ; Wed, 20 Feb 2013 11:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnchLfCTgctw for ; Wed, 20 Feb 2013 11:29:54 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDFA1F0C4E for ; Wed, 20 Feb 2013 11:29:54 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id b4so3844365qen.18 for ; Wed, 20 Feb 2013 11:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OeIG6J0Wl55o7zCjPwTgy4nmNWwwa5fkvMQ5spyTiSs=; b=TWw8jcQ4gphYLWGXMuvY+serIkCi3JObDPmzykzMZEeRFjnuauJyLEZP432U2BXXay atfcaSsYfkxqCc9Sis57wq2JxvNMya8CBUipRJpkBSUTfE3iIN36PVbKIP6A3xSp3cND n/BhrF7FUkSr/fHqYuSkQda3x/VtXz8ZGdB9ww270OAvc8wc7zLK7+qKrR5EH2RUuSzy HgyXha6bR/5kcdDMAhHzSMQl7eVduC9JJk3I57hoXFR4WZyxFQ/R5xUjdDcSl4JLwMWE PbEATgP3UN+ypk09rdE87WlfdR7E8pZo2STElUQsKt4Poep23QDKVATMse5W5MUHOsZ0 iQLQ== MIME-Version: 1.0 X-Received: by 10.224.186.15 with SMTP id cq15mr5705901qab.12.1361388593613; Wed, 20 Feb 2013 11:29:53 -0800 (PST) Received: by 10.49.24.133 with HTTP; Wed, 20 Feb 2013 11:29:53 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 14:29:53 -0500 Message-ID: From: Andrew Booth To: Eric McMurry , dime@ietf.org, ben@nostrum.com Content-Type: multipart/alternative; boundary=485b397dcdfb860d2104d62cfb4b Subject: Re: [Dime] Fw: Re: draft-ietf-dime-overload-reqs-03: some REQ comments and questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:32:21 -0000 --485b397dcdfb860d2104d62cfb4b Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, Sorry for the delay, comments inline. On Wed, Feb 20, 2013 at 11:12 AM, Andrew Booth wrote: > > > -----Forwarded by Andrew Booth/PTI on 02/20/2013 11:10AM ----- > To: Andrew Booth > From: Eric McMurry > Date: 02/16/2013 12:55PM > Cc: dime@ietf.org, ben@nostrum.com > Subject: Re: draft-ietf-dime-overload-reqs-03: some REQ comments and > questions > > Hi Andrew, > > Sorry for the delay. Please see inline. > > Thanks, > > Eric > > > On Feb 4, 2013, at 23:13 , Andrew Booth < abooth@pt.com> wrote: > > Some minor questions and comments on various requirements. > > REQ 7: I'm not sure that "the system remains stable" adds much on its own, > removing it doesn't seem to lose much: > ALT REQ 7: The overload control mechanism and any associated > default algorithm(s) MUST ensure that when the > offered load drops from above the overall > capacity of the network to below the overall > capacity, the throughput MUST stabilize and become > equal to the offered load. Note that this also > requires that the mechanism MUST allow nodes to > shed load without introducing oscillations. > > > The text after the first sentence was intended to elaborate on it. It > would probably read about the same either way, but I don't think it > detracts having it there. > Ok. > > REQ 7: query: Does this requirement imply that the proposed mechanism must > define one or more options for shedding load (as opposed to simply > requesting the clients to slow down)? Is it accurate to say that > processing TLS to get at the Diameter message may be a substantial part of > the message processing time, so a node may have limited ability to > distinguish between Diameter messages when shedding load? This query > applies to REQ 22 also. > > > I don't think this requirement implies that there be multiple algorithms, > but that is called out elsewhere (at least the ability to add them). > I think my question was poorly phrased, but perhaps it is not relevant anyway. To me there is a difference between shedding work locally (returning errors, throttling inbound messages, etc) vs sending load information to a peer who can reduce the amount they send. I wasn't clear which version of "shedding work" was referred to by REQ 7. Should the mechanism provide a way for an overloaded server to shed work locally? Or is that up to the mechanism? Both the existing proposals (as far as I can tell) only specify the behavior of a node that is sending a request; one of the proposals additionally specifies an error code that could potentially be used by a server, but no such procedures are specified (again, unless I missed something). > Impact of TLS is rather implementation dependent. I'm not sure what we > could say about that here (or that we should) > Ok. > > > > REQ 9: Is this simpler/clearer? Or did I miss some cross references? > ALT REQ 9: The mechanism MUST function across fully loaded as well > as > quiescent transport connections. This is partially derived > from REQ 7 above. > > > makes sense. good catch. > > > REQ 13: consider adding "The mechanism SHOULD NOT introduce substantial > additional work for nodes that are not in overload; in particular it should > not cause nodes to become overloaded". > > > not causing other nodes to be come overloaded is covered in req 12 and 23. > No introducing substantial work when not overloaded is probably a subset > of what is there. I think that was in an earlier version of the draft and > was considered redundant. Perhaps others remember that better. > Ok. > > > REQ 20: does "actual overload" deserve more clarification? For example, > would any or all of the following would represent "actual overload": CPU > usage, a deep send queue, messages incoming at an unexpectedly high rate? > Or is this something that would be defined by the proposed mechanism? Or > have I misunderstood completely? > > > the word actual may not actually add anything here. All of the things you > mentioned could be causes of overload. I think the intent though is that > existing Diameter errors not be overloaded to be used for overload. Any > overload control mechanism needs to be clear about what is being > communicated. > Ok. I'm fine with leaving it as it is, or removing "actual". Aside: I'm left wondering though whether the wording of this requirement prevents overload signaling from being used by an agent to signal unavailability of a server via that agent. Allowing node unavailability to be signaled as overload could have some nice benefits. > > > REQ 21: Does this imply that a node must be able to deduce overload of a > peer or indirectly accessible node based on local metrics only (response > time, send queue depth, etc)? Since "The mechanism MUST properly function > in these cases", does that require that explicit messaging is unnecessary? > > > perhaps "properly function" should be stated differently. The intent here > is that the mechanism not break things in this case and that the overload > is handled at least as well as it would have been were the overload control > signaling intact. The language in req 17 is close to this point I think. > How about we barrow that language? > > REQ 21: In cases where a network node fails, is so overloaded that > it cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > congestion. The mechanism MUST result > in at least as much useful throughput as would have resulted > if the overload control signaling were present. > > > This may imply the actions you mention, as so other requirements around > functioning in environments with nodes that do, and do not support the > mechanism, and fairness in that case. Overload can be mitigated somewhat > without overload control signaling, but that is not sufficient to handle > issues that are occurring on networks now. A good bit of the front matter > in the draft discusses this point. > It seems to me that if overload signaling is worthwhile, it must be because it increases useful throughput (at least in some cases). So I would expect that useful throughput without overload procedures <= useful throughput with only local overload procedures <= useful throughput with explicit signaling. Hence I would expect something more like this: ALT REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of congestion. In this case, actions based on local metrics at the affected or adjacent nodes may still provide some benefit. The mechanism MUST result in at least as much useful throughput as if the affected nodes did not implement the mechanism. The mechanism SHOULD result in more useful throughput than if none of the nodes implemented the mechanism. Does that make sense? Or have I misunderstood completely? > > REQ 29: query: why do we need to know who sent the overload info (note > that the security concerns are addressed in other requirements)? Do we > lose anything by removing the first sentence? > ALT REQ 29: The mechanism MUST allow a node to distinguish between > overload at a next-hop peer from overload at a node upstream > of the peer. For example, in Figure 5, the client must not > mistake overload at server 1 for overload at the agent, > whether or not the agent supports the mechanism. > REQ 29: nit: why the cross reference to REQ 4? > > > I agree with this and would go further. Upon reading this again, I don't > think req 29 is adding anything. Perhaps we should just add this example > to 33 and remove 29. > That works for me. > > > REQ 33: "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.": > this wording seems to imply that the mechanism must support overload > specification of arbitrary granularity, with a corresponding increase in > the complexity required on implementations. Even supporting "Diameter > session" could force a node to maintain session state when it is otherwise > not required (more an issue for Agents than end nodes), at a corresponding > increase in the cost and complexity of that node. Is there anything to be > concerned about here? Or is REQ 13 sufficient to limit complexity? > > > I think req 13 probably covers this. I understand your concern though, > and share it. There is potential for significant complexity. There have > been a lot of comments on this point and I think there will be a fair > amount of thinking going into appropriate scoping of overload control > information in ways that balance work imposed on nodes with capacity left > on the table. Perhaps adding the word "unreasonably" in between "without" > and "forcing" would make folks feel more comfortable that the necessary > wiggle room is here for the mechanism specifiers. > That works. > > REQ 35: query: explicitly mention that end-to-end security is required > here? Or is it not? > > REQ 35: query: does this pretty much rule out strictly a hop-by-hop > approach? > > > Jouni answered these last two and that looked reasonable to me. > Ok. Thanks, Andrew > > > Thanks, > Andrew > > > --485b397dcdfb860d2104d62cfb4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric,

Sorry for the delay, comments i= nline.

On = Wed, Feb 20, 2013 at 11:12 AM, Andrew Booth <abooth@pt.com> wr= ote:

-----Forwarded by Andrew Booth/PTI on 02/20= /2013 11:10AM -----
To: Andrew Booth <abo= oth@pt.com>
From: Eric McMurry <emcmurry@computer.org>
Date: 02/16/2013 12:55PM
Cc: dime@ietf.org, ben@nostrum.com
Subject: Re: draft-ietf-dime-overload-reqs-03: = some REQ comments and questions

Hi Andrew,

Sorry for the delay. =A0Please see inline.

Thanks,

Eric

On Feb 4, 2013, at 23:13 , Andrew Booth < abooth@pt.com> wrote:

Some minor questi= ons and comments on various requirements.

REQ 7: I= 9;m not sure that "the system remains stable" adds much on its ow= n, removing it doesn't seem to lose much:
=A0 =A0 =A0= ALT REQ 7: The overload control mechanism and any associated
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0default algorithm(s) MUST ensure that when the
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0offered load drops from above the overall
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0capacity of the network to below the overall
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0capacity, the throughput MUST stabilize and become
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0equal to the offered load. =A0Note that this also
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0requires that the mechanism MUST allow nodes to
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0shed load without introducing oscillations.

The text after the first sent= ence was intended to elaborate on it. =A0It would probably read about the s= ame either way, but I don't think it detracts having it there.

Ok.
=A0

REQ 7:= query: Does this requirement imply that the proposed mechanism must define= one or more options for shedding load (as opposed to simply requesting the= clients to slow down)? =A0Is it accurate to say that processing TLS to get= at the Diameter message may be a substantial part of the message processin= g time, so a node may have limited ability to distinguish between Diameter = messages when shedding load? =A0This query applies to REQ 22 also.

I don't think this requir= ement implies that there be multiple algorithms, but that is called out els= ewhere (at least the ability to add them).

I think my question was poorly phra= sed, but perhaps it is not relevant anyway.

To me there is a differe= nce between shedding work locally (returning errors, throttling inbound mes= sages, etc) vs sending load information to a peer who can reduce the amount= they send.=A0 I wasn't clear which version of "shedding work"= ; was referred to by REQ 7.

Should the mechanism provide a way for an overloaded server = to shed work locally?=A0 Or is that up to the mechanism?=A0 Both the existi= ng proposals (as far as I can tell) only specify the behavior of a node tha= t is sending a request; one of the proposals additionally specifies an erro= r code that could potentially be used by a server, but no such procedures a= re specified (again, unless I missed something).

Impact of TLS is rather implementation dependent. =A0I&= #39;m not sure what we could say about that here (or that we should)
<= /div>

Ok.
=A0

REQ 9: Is this si= mpler/clearer? =A0Or did I miss some cross references?
=A0 =A0 =A0= ALT REQ 9: =A0 The mechanism MUST function across fully loaded as well as<= /font>
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0quiescent transport connections. =A0This is partially d= erived
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0from REQ 7 above.

makes sense. =A0good catch.

REQ 13: consider = adding "The mechanism SHOULD NOT introduce substantial additional work= for nodes that are not in overload; in particular it should not cause node= s to become overloaded".

not causing other nodes to be= come overloaded is covered in req 12 and 23. =A0No introducing substantial= work when not overloaded is probably a subset of what is there. =A0I think= that was in an earlier version of the draft and was considered redundant. = =A0Perhaps others remember that better.

Ok.
=A0<= br>

REQ 20: does &quo= t;actual overload" deserve more clarification? =A0For example, would a= ny or all of the following would represent "actual overload": CPU= usage, a deep send queue, messages incoming at an unexpectedly high rate? = =A0Or is this something that would be defined by the proposed mechanism? = =A0Or have I misunderstood completely?

the word actual may not actua= lly add anything here. =A0All of the things you mentioned could be causes o= f overload. =A0I think the intent though is that existing Diameter errors n= ot be overloaded to be used for overload. =A0Any overload control mechanism= needs to be clear about what is being communicated.=A0

Ok.=A0 I= 9;m fine with leaving it as it is, or removing "actual".

A= side: I'm left wondering though whether the wording of this requirement= prevents overload signaling from being used by an agent to signal unavaila= bility of a server via that agent.=A0 Allowing node unavailability to be si= gnaled as overload could have some nice benefits.

=A0

REQ 21: Does this= imply that a node must be able to deduce overload of a peer or indirectly = accessible node based on local metrics only (response time, send queue dept= h, etc)? =A0Since "The mechanism MUST properly function in these cases= ", does that require that explicit messaging is unnecessary?

perhaps "properly functi= on" should be stated differently. =A0The intent here is that the mecha= nism not break things in this case and that the overload is handled at leas= t as well as it would have been were the overload control signaling intact.= =A0The language in req 17 is close to this point I think. =A0How about we = barrow that language?

REQ 21: =A0In cases where a network node fails, is= so overloaded that

=A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot communic= ate due to a

=A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able to provide= explicit

=A0 =A0 =A0 =A0 =A0 =A0 indications of the nature of the failure or it= s levels of

=A0 =A0 =A0 =A0 =A0 =A0 congestion. =A0The mechanism MUST=A0result
=A0 =A0 =A0 =A0 =A0 =A0 in at least as much useful throughput as would= have resulted

=A0 =A0 =A0 =A0 =A0 =A0 if the overload control signaling were present= .

This may imply the actions you men= tion, as so other requirements around functioning in environments with node= s that do, and do not support the mechanism, and fairness in that case. =A0= Overload can be mitigated somewhat without overload control signaling, but = that is not sufficient to handle issues that are occurring on networks now.= =A0A good bit of the front matter in the draft discusses this point.

It seems to me that if= overload signaling is worthwhile, it must be because it increases useful t= hroughput (at least in some cases).
So I would expect that useful throughput without overload procedures <= =3D useful throughput with only local overload procedures <=3D useful th= roughput with explicit signaling.=A0 Hence I would expect something more li= ke this:

=A0=A0 ALT REQ 21:=A0 In cases where a network node fails, is so overlo= aded that
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 it cannot process messages, = or cannot communicate due to a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 network= failure, it may not be able to provide explicit
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 indications of the nature of the failure = or its levels of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 congestion.=A0 In thi= s case, actions based on local metrics at the affected
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 or adjacent nodes may still provide some benefit.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The mechanism MUST result in at least as = much useful throughput as
=A0 =A0 =A0 =A0 =A0 =A0 if the affected nodes = did not implement the mechanism.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The m= echanism SHOULD result in more useful throughput than if none
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of the nodes implemented the mechanism.
Does that make sense?=A0 Or have I misunderstood completely?

<= /div>

REQ 29: query: wh= y do we need to know who sent the overload info (note that the security con= cerns are addressed in other requirements)? =A0Do we lose anything by remov= ing the first sentence?
=A0 =A0 =A0= ALT REQ 29: =A0The mechanism MUST allow a node to distinguish between
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0overload at a next-hop peer from overload at a node ups= tream
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0of the peer. =A0For example, in Figure 5, the client mu= st not
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0mistake overload at server 1 for overload at the agent,=
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0whether or not the agent supports the mechanism.
REQ 29: nit= : why the cross reference to REQ 4?

I agree with this and would g= o further. =A0Upon reading this again, I don't think req 29 is adding a= nything. =A0Perhaps we should just add this example to 33 and remove 29.

That works = for me.
=A0

<= font face=3D"Default Sans Serif,Verdana,Arial,Helvetica,sans-serif">

REQ 33: &quo= t;The mechanism MUST allow Diameter nodes to indicate overload with suffici= ent granularity to allow clients to take action based on the overloaded res= ources without forcing available capacity to go unused.": this wording= seems to imply that the mechanism must support overload specification of a= rbitrary granularity, with a corresponding increase in the complexity requi= red on implementations. =A0Even supporting "Diameter session" cou= ld force a node to maintain session state when it is otherwise not required= (more an issue for Agents than end nodes), at a corresponding increase in = the cost and complexity of that node. =A0Is there anything to be concerned = about here? =A0Or is REQ 13 sufficient to limit complexity?

I think req 13 probabl= y covers this. =A0I understand your concern though, and share it. =A0There = is potential for significant complexity. =A0There have been a lot of commen= ts on this point and I think there will be a fair amount of thinking going = into appropriate scoping of overload control information in ways that balan= ce work imposed on nodes with capacity left on the table. Perhaps adding th= e word "unreasonably" in between "without" and "fo= rcing" would make folks feel more comfortable that the necessary wiggl= e room is here for the mechanism specifiers.

That works.=

REQ 35: query: explicitly mention that end-to-end security is required= here? =A0Or is it not?

REQ 35: query: does this pretty much rule out strictly = a hop-by-hop approach?

Jouni answered these l= ast two and that looked reasonable to me.

Ok.

Thanks,
Andrew=

Thanks,
Andrew

--485b397dcdfb860d2104d62cfb4b-- From emcmurry@computer.org Wed Feb 20 11:38:36 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A821F86CB for ; Wed, 20 Feb 2013 11:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OabaS6RYdmMp for ; Wed, 20 Feb 2013 11:38:36 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 638DC21F869A for ; Wed, 20 Feb 2013 11:38:36 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8FUx-000IGv-Tf for dime@ietf.org; Wed, 20 Feb 2013 19:38:36 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 12C121F17295 for ; Wed, 20 Feb 2013 13:38:35 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+9xngnJljk//gkWHi306cxx7ncjq/Vfig= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaF7lME0n2-b for ; Wed, 20 Feb 2013 13:38:35 -0600 (CST) Received: from [10.12.10.62] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id E8DF11F1728F for ; Wed, 20 Feb 2013 13:38:34 -0600 (CST) From: Eric McMurry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> Date: Wed, 20 Feb 2013 13:38:34 -0600 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) X-Mailer: Apple Mail (2.1499) Subject: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:38:36 -0000 Req 7 reads: The overload control mechanism and any associated default algorithm(s) MUST ensure that the system remains stable. When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput MUST stabilize and become equal to the offered load. Note that this also requires that the mechanism MUST allow nodes to shed load without introducing oscillations. It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound: The overload control mechanism and any associated default algorithm(s) MUST ensure that the system remains stable. When the offered load drops from above the overall capacity of the network to below the overall capacity, the mechanism MUST enable throughput to stabilize and become equal to the offered load. Note that this also requires that the mechanism MUST allow nodes to shed load without introducing oscillations. Thanks, Eric From emcmurry@computer.org Wed Feb 20 11:38:41 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99CB21F8716 for ; Wed, 20 Feb 2013 11:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiEk-To+FAMj for ; Wed, 20 Feb 2013 11:38:41 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC421F84ED for ; Wed, 20 Feb 2013 11:38:41 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8FV2-000Pjv-TS for dime@ietf.org; Wed, 20 Feb 2013 19:38:40 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 758261F172A7 for ; Wed, 20 Feb 2013 13:38:40 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+IX2slOy+NpJ1qujE3qLjYchwyW4JvHDU= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4nOJ39JD8Vz for ; Wed, 20 Feb 2013 13:38:40 -0600 (CST) Received: from [10.12.10.62] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 520B31F172A1 for ; Wed, 20 Feb 2013 13:38:40 -0600 (CST) From: Eric McMurry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 20 Feb 2013 13:38:40 -0600 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) X-Mailer: Apple Mail (2.1499) Subject: [Dime] overload control reqs on minimizing effects X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:38:42 -0000 It has been pointed out that there is overlap between Req 12, and Req = 23, and that the second clause of Req 23 may run afoul of other reqs = around local policy. I think the second clause of 23 is probably not = adding anything and would be safe to remove. The first clause does not = seem to cover anything that is not in Req 12. Perhaps we should remove = 23 entirely? thanks, Eric =20= From emcmurry@computer.org Wed Feb 20 11:38:45 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2521F84ED for ; Wed, 20 Feb 2013 11:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkKIkENPcocI for ; Wed, 20 Feb 2013 11:38:44 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 942AE21F888B for ; Wed, 20 Feb 2013 11:38:44 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8FV6-000PmI-7E for dime@ietf.org; Wed, 20 Feb 2013 19:38:44 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id E95391F172AE for ; Wed, 20 Feb 2013 13:38:43 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX189PGXLdYufSq+nvgTRuTM02dGhOKTIn5c= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxWLUChtfGGQ for ; Wed, 20 Feb 2013 13:38:43 -0600 (CST) Received: from [10.12.10.62] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id C88DD1F172A8 for ; Wed, 20 Feb 2013 13:38:43 -0600 (CST) From: Eric McMurry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 20 Feb 2013 13:38:43 -0600 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) X-Mailer: Apple Mail (2.1499) Subject: [Dime] overload control requirement 10 on end of overload condition X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:38:45 -0000 Req 10 reads: Consumers of overload state indications MUST be able to determine when the overload condition improves or ends. It has been pointed out that the term "overload state indications" may = imply aspects of implementation. In the rest of the document the more = generic "overload information" is generally used. I think it would make = sense to use that here as well. So Req 10 would read: Consumers of overload information MUST be able to determine when the overload condition improves or ends. Thanks, Eric From emcmurry@computer.org Wed Feb 20 11:38:49 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0743921F89EF for ; Wed, 20 Feb 2013 11:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTaTZNCDnpmO for ; Wed, 20 Feb 2013 11:38:48 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE121F89C7 for ; Wed, 20 Feb 2013 11:38:48 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8FVA-000Poh-7S for dime@ietf.org; Wed, 20 Feb 2013 19:38:48 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id E90001F172C8 for ; Wed, 20 Feb 2013 13:38:47 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19xmBMRUFQCPk8Kmw4xKeAA0vmn/zZozP8= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAI1qwUOhmIW for ; Wed, 20 Feb 2013 13:38:47 -0600 (CST) Received: from [10.12.10.62] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id C43A81F172C2 for ; Wed, 20 Feb 2013 13:38:47 -0600 (CST) From: Eric McMurry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 20 Feb 2013 13:38:47 -0600 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) X-Mailer: Apple Mail (2.1499) Subject: [Dime] overload control req 16 is needed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:38:49 -0000 It has been pointed out that Req 16 has some ambiguity to it, around the = meaning of "without malfunction". Looking at it a bit closer, along = with the next couple of requirements, it does not seem to be adding = anything. I think Reqs 17 and 18 cover what this was trying to = communicate, and it would make things more clear to just remove it. = Does this make sense? Thanks, Eric From ben@nostrum.com Wed Feb 20 11:44:03 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5C721E8041 for ; Wed, 20 Feb 2013 11:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEBTaewqQCDP for ; Wed, 20 Feb 2013 11:44:03 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E2AB421E803F for ; Wed, 20 Feb 2013 11:44:02 -0800 (PST) Received: from [10.119.79.98] (v398.dal.ubiquity.io [174.34.133.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1KJhvwh050494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 13:43:59 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ben Campbell In-Reply-To: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> Date: Wed, 20 Feb 2013 13:43:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <411C3247-1618-43A7-9E66-C6C6DB70342C@nostrum.com> References: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 174.34.133.219 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:44:03 -0000 On Feb 20, 2013, at 1:38 PM, Eric McMurry wrote: > Req 7 reads: The overload control mechanism and any associated = default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall capacity > of the network to below the overall capacity, the = throughput > MUST stabilize and become equal to the offered load. Note > that this also requires that the mechanism MUST allow nodes > to shed load without introducing oscillations. >=20 >=20 > It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound: >=20 >=20 > The overload control mechanism and any associated default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall capacity > of the network to below the overall capacity, the mechanism > MUST enable throughput to stabilize and become > equal to the offered load. Note > that this also requires that the mechanism MUST allow nodes > to shed load without introducing oscillations. >=20 >=20 WFM.= From ben@nostrum.com Wed Feb 20 11:44:28 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FBE21E803F for ; Wed, 20 Feb 2013 11:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGLfh0UlCcXw for ; Wed, 20 Feb 2013 11:44:28 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EDCFF21E803C for ; Wed, 20 Feb 2013 11:44:27 -0800 (PST) Received: from [10.119.79.98] (v398.dal.ubiquity.io [174.34.133.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1KJhvwi050494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 13:44:19 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ben Campbell In-Reply-To: Date: Wed, 20 Feb 2013 13:44:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5270514C-BBA5-46B2-8AA0-961259B9279F@nostrum.com> References: To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 174.34.133.219 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control reqs on minimizing effects X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:44:28 -0000 On Feb 20, 2013, at 1:38 PM, Eric McMurry wrote: > It has been pointed out that there is overlap between Req 12, and Req = 23, and that the second clause of Req 23 may run afoul of other reqs = around local policy. I think the second clause of 23 is probably not = adding anything and would be safe to remove. The first clause does not = seem to cover anything that is not in Req 12. Perhaps we should remove = 23 entirely? >=20 I concur with removing 23 in it's entirety. >=20 > thanks, >=20 > Eric >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Wed Feb 20 11:44:54 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DD421E804D for ; Wed, 20 Feb 2013 11:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UKnUhTs34Sf for ; Wed, 20 Feb 2013 11:44:53 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3C21E804C for ; Wed, 20 Feb 2013 11:44:53 -0800 (PST) Received: from [10.119.79.98] (v398.dal.ubiquity.io [174.34.133.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1KJhvwj050494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 13:44:50 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ben Campbell In-Reply-To: Date: Wed, 20 Feb 2013 13:44:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 174.34.133.219 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 10 on end of overload condition X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:44:54 -0000 On Feb 20, 2013, at 1:38 PM, Eric McMurry wrote: > Req 10 reads: Consumers of overload state indications MUST be able to > determine when the overload condition improves or ends. >=20 > It has been pointed out that the term "overload state indications" may = imply aspects of implementation. In the rest of the document the more = generic "overload information" is generally used. I think it would make = sense to use that here as well. So Req 10 would read: >=20 > Consumers of overload information MUST be able to > determine when the overload condition improves or ends. WFM= From lists.abooth@gmail.com Wed Feb 20 11:50:25 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3C21F8619 for ; Wed, 20 Feb 2013 11:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XCrCTfebrh7 for ; Wed, 20 Feb 2013 11:50:24 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id B8DB921F85F5 for ; Wed, 20 Feb 2013 11:50:24 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id 1so3926347qec.33 for ; Wed, 20 Feb 2013 11:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zwOuMOKNpRp3WE5EpG5dFjKwK3fjVaRVVNclzMpkBBs=; b=t5IJN7XX/B6zTAg9+bvh1nZAiC5xWE2BGxDcIZUnmii19zQPdx4Gf+GX5KCZQ1fhQg fAbeZa68053ps5OGVgYYSaMw4D2d+Hy8x+3zKIKZhCSPdQxTfisBx0aYSige5FoCgnSf bIBBsBRdNe0j7V7Pqlc8h1aulTD6A4ICQ+2YnSYCihnkkJH0iNsFg2AEY0uLO6gON0JY BmyjMUpTC9kbr+iv7DHk9QlKGN55GvSF+D5IzNkKyqvG3/NX23MUg+04Bgt5HqbenSyJ H4HjkRP844ugnK+/zVLWGQ7WJYj7e9tHAt0+ZnRrMqwu5b34RzoV+fRwrKINJPaw17v+ dt5g== MIME-Version: 1.0 X-Received: by 10.49.12.138 with SMTP id y10mr10453503qeb.64.1361389824278; Wed, 20 Feb 2013 11:50:24 -0800 (PST) Received: by 10.49.24.133 with HTTP; Wed, 20 Feb 2013 11:50:24 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 14:50:24 -0500 Message-ID: From: Andrew Booth To: Eric McMurry Content-Type: multipart/alternative; boundary=047d7b6d88b2e0823104d62d441e Cc: "dime@ietf.org" Subject: Re: [Dime] overload control req 16 is needed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:50:25 -0000 --047d7b6d88b2e0823104d62d441e Content-Type: text/plain; charset=ISO-8859-1 That works for me. Thanks, Andrew On Wed, Feb 20, 2013 at 2:38 PM, Eric McMurry wrote: > It has been pointed out that Req 16 has some ambiguity to it, around the > meaning of "without malfunction". Looking at it a bit closer, along with > the next couple of requirements, it does not seem to be adding anything. I > think Reqs 17 and 18 cover what this was trying to communicate, and it > would make things more clear to just remove it. Does this make sense? > > Thanks, > > Eric > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --047d7b6d88b2e0823104d62d441e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That works for me.

Thanks,
Andrew

On Wed, Feb 20, 2013 at 2:38 PM, Eric McMurry <emcmurry@computer.or= g> wrote:

It has been pointed out that Req 16 has some= ambiguity to it, around the meaning of "without malfunction". = =A0Looking at it a bit closer, along with the next couple of requirements, = it does not seem to be adding anything. =A0I think Reqs 17 and 18 cover wha= t this was trying to communicate, and it would make things more clear to ju= st remove it. =A0Does this make sense?

Thanks,

Eric

_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--047d7b6d88b2e0823104d62d441e-- From lists.abooth@gmail.com Wed Feb 20 11:52:07 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FC421F866F for ; Wed, 20 Feb 2013 11:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjn8hZsPF4nO for ; Wed, 20 Feb 2013 11:52:06 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBCD21F8619 for ; Wed, 20 Feb 2013 11:52:06 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id bs12so2603060qab.18 for ; Wed, 20 Feb 2013 11:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qKUHeRG0+laJGNiieFNDr/ajNmOCqZFwzr1whSkaBkM=; b=cN3au1HuYcWB2C86trNrLMWv5E9kGJ9QoRzJQ1FuVzPeeNBe72+O9twWKrCVwGkHLs hkVoA6U/y3JunYeKXx+u6q1TqNjSlf0AbFXAOeTpqaz7HCVZnduz1HOSIGG7I3kZE0gy AT1yMgn8nOrsP4bITvww32GCC/jL5+/2OIn8d5fxmBxhQkhX4REWc2AnaI7z15u8Eapq xuFiJqV3bvozp2+oaXyXISPCed5ay4tRhcF62Wt6xdr392oaBg1qZZwowotB/7AKOh+s LiGsGOCVYt//JCmeLdjwqRoFp2smwIZrCtKGQghxqNvTGvNfLlUJqfCCKFXzkP1UwaKy edOw== MIME-Version: 1.0 X-Received: by 10.229.175.6 with SMTP id v6mr2252476qcz.4.1361389925777; Wed, 20 Feb 2013 11:52:05 -0800 (PST) Received: by 10.49.24.133 with HTTP; Wed, 20 Feb 2013 11:52:05 -0800 (PST) In-Reply-To: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> References: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> Date: Wed, 20 Feb 2013 14:52:05 -0500 Message-ID: From: Andrew Booth To: Eric McMurry Content-Type: multipart/alternative; boundary=0016e68fcedbed3fb704d62d4a31 Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:52:07 -0000 --0016e68fcedbed3fb704d62d4a31 Content-Type: text/plain; charset=ISO-8859-1 Works for me. Thanks, Andrew On Wed, Feb 20, 2013 at 2:38 PM, Eric McMurry wrote: > Req 7 reads: The overload control mechanism and any associated default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall capacity > of the network to below the overall capacity, the throughput > MUST stabilize and become equal to the offered load. Note > that this also requires that the mechanism MUST allow nodes > to shed load without introducing oscillations. > > > It has been pointed out that the latter part of this implies requirements > directly on nodes implementing the mechanism, instead of on the mechanism > itself. How does this alternate sound: > > > The overload control mechanism and any associated default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall capacity > of the network to below the overall capacity, the mechanism > MUST enable throughput to stabilize and become > equal to the offered load. Note > that this also requires that the mechanism MUST allow nodes > to shed load without introducing oscillations. > > > Thanks, > > Eric > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0016e68fcedbed3fb704d62d4a31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Works for me.

Thanks,
Andrew

On= Wed, Feb 20, 2013 at 2:38 PM, Eric McMurry <emcmurry@computer.org> wrote:

Req 7 reads: =A0The overload control mechani= sm and any associated default
=A0 =A0 =A0 =A0 =A0 =A0 algorithm(s) MUST ensure that the system remains st= able.
=A0 =A0 =A0 =A0 =A0 =A0 When the offered load drops from above the overall = capacity
=A0 =A0 =A0 =A0 =A0 =A0 of the network to below the overall capacity, the t= hroughput
=A0 =A0 =A0 =A0 =A0 =A0 MUST stabilize and become equal to the offered load= . =A0Note
=A0 =A0 =A0 =A0 =A0 =A0 that this also requires that the mechanism MUST all= ow nodes
=A0 =A0 =A0 =A0 =A0 =A0 to shed load without introducing oscillations.

It has been pointed out that the latter part of this implies requirements d= irectly on nodes implementing the mechanism, instead of on the mechanism it= self. =A0How does this alternate sound:

=A0 =A0The overload control mechanism and any associated default
=A0 =A0 =A0 =A0 =A0 =A0 algorithm(s) MUST ensure that the system remains st= able.
=A0 =A0 =A0 =A0 =A0 =A0 When the offered load drops from above the overall = capacity
=A0 =A0 =A0 =A0 =A0 =A0 of the network to below the overall capacity, the m= echanism
=A0 =A0 =A0 =A0 =A0 =A0 MUST enable throughput to stabilize and become
=A0 =A0 =A0 =A0 =A0 =A0 equal to the offered load. =A0Note
=A0 =A0 =A0 =A0 =A0 =A0 that this also requires that the mechanism MUST all= ow nodes
=A0 =A0 =A0 =A0 =A0 =A0 to shed load without introducing oscillations.

Thanks,

Eric

_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--0016e68fcedbed3fb704d62d4a31-- From ben@nostrum.com Wed Feb 20 11:52:41 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C7521F8698 for ; Wed, 20 Feb 2013 11:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OLNwbUS28T4 for ; Wed, 20 Feb 2013 11:52:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED7C21F8619 for ; Wed, 20 Feb 2013 11:52:40 -0800 (PST) Received: from [10.119.79.98] (v398.dal.ubiquity.io [174.34.133.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1KJqWXh051574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 13:52:33 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ben Campbell In-Reply-To: Date: Wed, 20 Feb 2013 13:52:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <461BC1A5-C193-44D4-9AF7-C0D256AD59F9@nostrum.com> References: To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 174.34.133.219 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control req 16 is needed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:52:41 -0000 On Feb 20, 2013, at 1:38 PM, Eric McMurry wrote: > It has been pointed out that Req 16 has some ambiguity to it, around = the meaning of "without malfunction". Looking at it a bit closer, along = with the next couple of requirements, it does not seem to be adding = anything. I think Reqs 17 and 18 cover what this was trying to = communicate, and it would make things more clear to just remove it. = Does this make sense? In retrospect, I'm not sure I agree with this one. 16 is the requirement = that explicitly requires support for mixed environment. 17 and 18 = further constrain that. If we remove 16, then 17 and 18 will still = _imply_ the requirement to support mixed environments--but it's better = to be explicit. How about the following alternative text for 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." >=20 > Thanks, >=20 > Eric >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Wed Feb 20 11:54:26 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B845121F86BE for ; Wed, 20 Feb 2013 11:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiRZSo0RdJEI for ; Wed, 20 Feb 2013 11:54:26 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB421F8698 for ; Wed, 20 Feb 2013 11:54:25 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8FkH-0009OA-Gr; Wed, 20 Feb 2013 19:54:25 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 57AC21F17E35; Wed, 20 Feb 2013 13:54:24 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Z95KYEfl/218ne46y/bDiaDCbe33irIA= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lR1BKWXjVBI; Wed, 20 Feb 2013 13:54:24 -0600 (CST) Received: from [10.12.10.62] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 1D0DF1F17E2E; Wed, 20 Feb 2013 13:54:24 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: <461BC1A5-C193-44D4-9AF7-C0D256AD59F9@nostrum.com> Date: Wed, 20 Feb 2013 13:54:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0462197C-0900-496B-A984-242A6C1FFBCA@computer.org> References: <461BC1A5-C193-44D4-9AF7-C0D256AD59F9@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control req 16 is needed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:54:26 -0000 On Feb 20, 2013, at 13:52 , Ben Campbell wrote: >=20 > On Feb 20, 2013, at 1:38 PM, Eric McMurry = wrote: >=20 >> It has been pointed out that Req 16 has some ambiguity to it, around = the meaning of "without malfunction". Looking at it a bit closer, along = with the next couple of requirements, it does not seem to be adding = anything. I think Reqs 17 and 18 cover what this was trying to = communicate, and it would make things more clear to just remove it. = Does this make sense? >=20 > In retrospect, I'm not sure I agree with this one. 16 is the = requirement that explicitly requires support for mixed environment. 17 = and 18 further constrain that. If we remove 16, then 17 and 18 will = still _imply_ the requirement to support mixed environments--but it's = better to be explicit. >=20 > How about the following alternative text for 16: >=20 > "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." >=20 wfm From lists.abooth@gmail.com Wed Feb 20 12:02:13 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A728921E803A for ; Wed, 20 Feb 2013 12:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxnT7McGdFnz for ; Wed, 20 Feb 2013 12:02:13 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4821F874F for ; Wed, 20 Feb 2013 12:02:12 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id 6so3874973qea.38 for ; Wed, 20 Feb 2013 12:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U0QCbdHTK4rKNfB8KBnzzXZCZygK4PEapWxXg+Qt0v0=; b=aXmP6jiphQk8jrN8u0/IIADxIC8q6QK9b+2b5j/r1kJWIvXfD90L/pYXk5uImV26+2 QSwD5ZGJoMj4r9Wd07F+4Vf80vZOoKi+F6uBvXWXUikBXLhE04OZCMnRH/3DJxV0Rsek XYy6T40Dl3UM+aH/6uZmKgPCvq7SjHq//lpHL5pt/If6cRJzrs3GY33cg33u+o14kGaK qWKLZSMiVynXCH0JihvBYJOSaW/lHo5/mqG7LnBnklnb5g/VAw7FmiawxGebcbFsKPPA FCQmslIFYtvr8vLClHMBbQUptaghl63sT2OQVB6ZF1PXUdjZLxgYbVSabpz2ngxbYNyg XSLg== MIME-Version: 1.0 X-Received: by 10.224.178.77 with SMTP id bl13mr10298722qab.13.1361390532377; Wed, 20 Feb 2013 12:02:12 -0800 (PST) Received: by 10.49.24.133 with HTTP; Wed, 20 Feb 2013 12:02:12 -0800 (PST) In-Reply-To: <0462197C-0900-496B-A984-242A6C1FFBCA@computer.org> References: <461BC1A5-C193-44D4-9AF7-C0D256AD59F9@nostrum.com> <0462197C-0900-496B-A984-242A6C1FFBCA@computer.org> Date: Wed, 20 Feb 2013 15:02:12 -0500 Message-ID: From: Andrew Booth To: Eric McMurry Content-Type: multipart/alternative; boundary=20cf302ef79e153d6a04d62d6f9b Cc: "dime@ietf.org" Subject: Re: [Dime] overload control req 16 is needed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:02:13 -0000 --20cf302ef79e153d6a04d62d6f9b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 20, 2013 at 2:54 PM, Eric McMurry wrote: > > On Feb 20, 2013, at 13:52 , Ben Campbell wrote: > > > > > On Feb 20, 2013, at 1:38 PM, Eric McMurry wrote: > > > >> It has been pointed out that Req 16 has some ambiguity to it, around > the meaning of "without malfunction". Looking at it a bit closer, along > with the next couple of requirements, it does not seem to be adding > anything. I think Reqs 17 and 18 cover what this was trying to > communicate, and it would make things more clear to just remove it. Does > this make sense? > > > > In retrospect, I'm not sure I agree with this one. 16 is the requirement > that explicitly requires support for mixed environment. 17 and 18 further > constrain that. If we remove 16, then 17 and 18 will still _imply_ the > requirement to support mixed environments--but it's better to be explicit. > > > > How about the following alternative text for 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." > > > > > wfm > I'm fine with either removing 16 or the alternate text proposed here, to me they are about the same. Thanks, Andrew > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --20cf302ef79e153d6a04d62d6f9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 20, 2013 at 2:54 PM, Eric Mc= Murry <emcmurry@computer.org> wrote:

On Feb 20, 2013, at 13:52 , Ben Campbell <ben@nostrum.com> wrote:

>
> On Feb 20, 2013, at 1:38 PM, Eric McMurry <emcmurry@computer.org> wrote:
>
>> It has been pointed out that Req 16 has some ambiguity to it, arou= nd the meaning of "without malfunction". =A0Looking at it a bit c= loser, along with the next couple of requirements, it does not seem to be a= dding anything. =A0I think Reqs 17 and 18 cover what this was trying to com= municate, and it would make things more clear to just remove it. =A0Does th= is make sense?
>
> In retrospect, I'm not sure I agree with this one. 16 is the requi= rement that explicitly requires support for mixed environment. 17 and 18 fu= rther constrain that. If we remove 16, then 17 and 18 will still _imply_ th= e requirement to support mixed environments--but it's better to be expl= icit.
>
> How about the following alternative text for 16:
>
> "The overload control mechanism is likely to be deployed incremen= tally. The mechanism MUST support a mixed environment where some but, not a= ll, nodes implement it."
>

wfm

I'm fine with either removing 16 or = the alternate text proposed here, to me they are about the same.

Tha= nks,
Andrew
=A0

_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--20cf302ef79e153d6a04d62d6f9b-- From jgunn6@csc.com Wed Feb 20 12:12:31 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7958721F8809; Wed, 20 Feb 2013 12:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.78 X-Spam-Level: X-Spam-Status: No, score=-6.78 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh14ZCYMrQ7Z; Wed, 20 Feb 2013 12:12:29 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2721F8806; Wed, 20 Feb 2013 12:12:29 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-86.messagelabs.com!1361391129!45642509!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26107 invoked from network); 20 Feb 2013 20:12:11 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Feb 2013 20:12:11 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1KKC5aV000525; Wed, 20 Feb 2013 15:12:05 -0500 In-Reply-To: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <93EA4687-35BC-4BF8-A61B-58EC72839D9E@nostrum.com> To: Eric McMurry MIME-Version: 1.0 X-KeepSent: 60BE12C7:0A88872D-85257B18:006D1ED5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 20 Feb 2013 15:12:02 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 02/20/2013 03:06:51 PM, Serialize complete at 02/20/2013 03:06:51 PM Content-Type: multipart/alternative; boundary="=_alternative 006EF70885257B18_=" Cc: dime-bounces@ietf.org, "dime@ietf.org" Subject: [Dime] Emergency Re: draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:12:31 -0000 This is a multipart message in MIME format. --=_alternative 006EF70885257B18_= Content-Type: text/plain; charset="US-ASCII" Being actively involved with one type of "emergency" messages, I prefer that protocol documents NOT specify how "emergency" requests should be treated. I much prefer wording that simply says that the overload protocol will not prevent the node from applying "local policy" with regard to selecting which messages to reject, as long as the desired reduction in traffic is achieved. Here is the current SIP wording "During an overload condition, a SIP client needs to prioritize requests and select those requests that need to be rejected or redirected. This selection is largely a matter of local policy. It is expected that a SIP client will follow local policy as long as the result in reduction of traffic is consistent with the overload algorithm in effect at that node. Accordingly, the normative behaviour in the next three paragraphs should be interpreted with the understanding that the SIP client will aim to preserve local policy to the fullest extent possible. A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs versus requests associated with existing sessions. A SIP client SHOULD honor the local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low- priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor the local policy for prioritizing SIP requests relating to emergency calls as identified by the SOS URN [RFC5031] indicating an emergency request. A local policy can be expected to combine both the SIP request type and the prioritization markings, and SHOULD be honored when overload conditions prevail." Obviously the DIME wording can not be as specific, as there are not specific "emergency related" markings. Maybe something like "During an overload condition, a DIAMETER node needs to prioritize requests and select those requests that need to be rejected or redirected. This selection is largely a matter of local policy. It is expected that a DIAMETER node will follow local policy as long as the result in reduction of traffic is consistent with the overload algorithm in effect at that node. Accordingly, the normative behaviour in the next two paragraphs should be interpreted with the understanding that the SIP client will aim to preserve local policy to the fullest extent possible. A DIAMETER node SHOULD honor the local policy for prioritizing DIAMETER requests such as policies based on type, e.g., messages associated with existing sessions vs messages associated with new sessions A DIAMETER node SHOULD honor the local policy for prioritizing DIAMETER requests associated with Emergency sessions vs. messages associated with non-Emergency sessions. A local policy can be expected to combine both the message type and the Emergency identification, and SHOULD be honored when overload conditions prevail." 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. dime-bounces@ietf.org wrote on 02/16/2013 02:31:24 PM: > From: Eric McMurry > To: Ben Campbell > Cc: "dime@ietf.org" > Date: 02/16/2013 02:31 PM > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > Sent by: dime-bounces@ietf.org > > I still favor removing the emergency services example entirely to > avoid confusion, but this language is okay with me if folks are happy with it. > > > Thanks, > > Eric > > > On Feb 8, 2013, at 16:53 , Ben Campbell wrote: > > > > > > > On Feb 7, 2013, at 1:11 PM, "THIEBAUT, LAURENT (LAURENT)" > wrote: > > > >> 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. > >> > >> > > > > Hi, > > > > I think one possible issue here is the assumption that emergency > sessions priority is always true is incorrect. There may well be > uses of diameter that do not have such requirements. Most uses in a > _telecom_ environment will. How about something like the following: > > > > "... For example, it may be more beneficial to process messages > for existing sessions ahead of new sessions. Some networks may have > a requirement to give priority to requests associated with emergency > sessions. ..." > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=_alternative 006EF70885257B18_= Content-Type: text/html; charset="US-ASCII" Being actively involved with one type of "emergency" messages, I prefer that protocol documents NOT specify how "emergency" requests should be treated.

I much prefer wording that simply says that the overload protocol will not prevent the node from applying "local policy" with regard to selecting which messages to reject, as long as the desired reduction in traffic is achieved.

Here is the current SIP wording

"During an overload condition, a SIP client needs to prioritize
requests and select those requests that need to be rejected or
redirected. This selection is largely a matter of local policy. It
is expected that a SIP client will follow local policy as long as the
result in reduction of traffic is consistent with the overload
algorithm in effect at that node. Accordingly, the normative
behaviour in the next three paragraphs should be interpreted with the
understanding that the SIP client will aim to preserve local policy
to the fullest extent possible.

A SIP client SHOULD honor the local policy for prioritizing SIP
requests such as policies based on message type, e.g., INVITEs versus
requests associated with existing sessions.

A SIP client SHOULD honor the local policy for prioritizing SIP
requests based on the content of the Resource-Priority header (RPH,
RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may
indicate high priority requests that should be preserved as much as
possible during overload. The RPH contents can also indicate a low-
priority request that is eligible to be dropped during times of
overload.

A SIP client SHOULD honor the local policy for prioritizing SIP
requests relating to emergency calls as identified by the SOS URN
[RFC5031] indicating an emergency request.

A local policy can be expected to combine both the SIP request type
and the prioritization markings, and SHOULD be honored when overload
conditions prevail."

Obviously the DIME wording can not be as specific, as there are not specific "emergency related" markings.

Maybe something like
"During an overload condition, a DIAMETER node needs to prioritize
requests and select those requests that need to be rejected or
redirected. This selection is largely a matter of local policy. It
is expected that a DIAMETER node will follow local policy as long as the
result in reduction of traffic is consistent with the overload
algorithm in effect at that node. Accordingly, the normative
behaviour in the next two paragraphs should be interpreted with the
understanding that the SIP client will aim to preserve local policy
to the fullest extent possible.

A DIAMETER node SHOULD honor the local policy for prioritizing DIAMETER
requests such as policies based on type, e.g., messages associated
with existing sessions vs messages associated with new sessions

A DIAMETER node SHOULD honor the local policy for prioritizing DIAMETER
requests associated with Emergency sessions vs. messages associated with
non-Emergency sessions.

A local policy can be expected to combine both the message type
and the Emergency identification, and SHOULD be honored when overload
conditions prevail."

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.

dime-bounces@ietf.org wrote on 02/16/2013 02:31:24 PM: > From: Eric McMurry <emcmurry@computer.org>
> To: Ben Campbell <ben@nostrum.com>
> Cc: "dime@ietf.org" <dime@ietf.org>
> Date: 02/16/2013 02:31 PM
> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
> Sent by: dime-bounces@ietf.org
> > I still favor removing the emergency services example entirely to > avoid confusion, but this language is okay with me if folks are happy with it. > > > Thanks, > > Eric > > > On Feb 8, 2013, at 16:53 , Ben Campbell <ben@nostrum.com> wrote: > > > > > > > On Feb 7, 2013, at 1:11 PM, "THIEBAUT, LAURENT (LAURENT)" > <laurent.thiebaut@alcatel-lucent.com> wrote: > > > >> 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. > >> > >> > > > > Hi, > > > > I think one possible issue here is the assumption that emergency > sessions priority is always true is incorrect. There may well be > uses of diameter that do not have such requirements. Most uses in a > _telecom_ environment will. How about something like the following: > > > > "... For example, it may be more beneficial to process messages > for existing sessions ahead of new sessions. Some networks may have > a requirement to give priority to requests associated with emergency > sessions. ..." > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime --=_alternative 006EF70885257B18_=-- From emcmurry@computer.org Wed Feb 20 13:46:03 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE52E21E804D for ; Wed, 20 Feb 2013 13:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzWjg1wpFPtA for ; Wed, 20 Feb 2013 13:46:02 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 39F6821E8049 for ; Wed, 20 Feb 2013 13:46:02 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8HUH-000N6c-H7; Wed, 20 Feb 2013 21:46:01 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 689791F1CA7B; Wed, 20 Feb 2013 15:46:00 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/s8B7+rJdzUfagnKUF4OqMr4J+ksrfyUA= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV1lq_lOrrX2; Wed, 20 Feb 2013 15:46:00 -0600 (CST) Received: from [10.12.10.62] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 12FF71F1CA6A; Wed, 20 Feb 2013 15:46:00 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9962F381-6F21-4B2A-8E40-DDBC4054202C" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: Date: Wed, 20 Feb 2013 15:45:58 -0600 Message-Id: References:

To: Andrew Booth X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:46:03 -0000 --Apple-Mail=_9962F381-6F21-4B2A-8E40-DDBC4054202C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Andrew, comments inline. Thanks, Eric On Feb 20, 2013, at 13:29 , Andrew Booth wrote: > Hi Eric, >=20 > Sorry for the delay, comments inline. >=20 >=20 > On Wed, Feb 20, 2013 at 11:12 AM, Andrew Booth wrote: >=20 >=20 > -----Forwarded by Andrew Booth/PTI on 02/20/2013 11:10AM ----- > To: Andrew Booth > From: Eric McMurry > Date: 02/16/2013 12:55PM > Cc: dime@ietf.org, ben@nostrum.com > Subject: Re: draft-ietf-dime-overload-reqs-03: some REQ comments and = questions >=20 > Hi Andrew, >=20 > Sorry for the delay. Please see inline. >=20 > Thanks, >=20 > Eric >=20 >=20 > On Feb 4, 2013, at 23:13 , Andrew Booth < abooth@pt.com> wrote: >=20 [...] > =20 >=20 >> REQ 7: query: Does this requirement imply that the proposed mechanism = must define one or more options for shedding load (as opposed to simply = requesting the clients to slow down)? Is it accurate to say that = processing TLS to get at the Diameter message may be a substantial part = of the message processing time, so a node may have limited ability to = distinguish between Diameter messages when shedding load? This query = applies to REQ 22 also. >=20 > I don't think this requirement implies that there be multiple = algorithms, but that is called out elsewhere (at least the ability to = add them). >=20 > I think my question was poorly phrased, but perhaps it is not relevant = anyway. >=20 > To me there is a difference between shedding work locally (returning = errors, throttling inbound messages, etc) vs sending load information to = a peer who can reduce the amount they send. I wasn't clear which = version of "shedding work" was referred to by REQ 7. >=20 > Should the mechanism provide a way for an overloaded server to shed = work locally? Or is that up to the mechanism? Both the existing = proposals (as far as I can tell) only specify the behavior of a node = that is sending a request; one of the proposals additionally specifies = an error code that could potentially be used by a server, but no such = procedures are specified (again, unless I missed something). I don't think the requirements are specific on this point. A mechanism = could use local actions as well as remote requests for overload = mitigation. The mechanism has to support the remote requests at a = minimum though. [...] >=20 > =20 >=20 >>=20 >> REQ 20: does "actual overload" deserve more clarification? For = example, would any or all of the following would represent "actual = overload": CPU usage, a deep send queue, messages incoming at an = unexpectedly high rate? Or is this something that would be defined by = the proposed mechanism? Or have I misunderstood completely? >=20 > the word actual may not actually add anything here. All of the things = you mentioned could be causes of overload. I think the intent though is = that existing Diameter errors not be overloaded to be used for overload. = Any overload control mechanism needs to be clear about what is being = communicated.=20 >=20 > Ok. I'm fine with leaving it as it is, or removing "actual". >=20 > Aside: I'm left wondering though whether the wording of this = requirement prevents overload signaling from being used by an agent to = signal unavailability of a server via that agent. Allowing node = unavailability to be signaled as overload could have some nice benefits. That is certainly not the intent. I can see where your comment comes = from. Do others think we should change the wording here? >=20 > =20 >=20 >>=20 >> REQ 21: Does this imply that a node must be able to deduce overload = of a peer or indirectly accessible node based on local metrics only = (response time, send queue depth, etc)? Since "The mechanism MUST = properly function in these cases", does that require that explicit = messaging is unnecessary? >=20 > perhaps "properly function" should be stated differently. The intent = here is that the mechanism not break things in this case and that the = overload is handled at least as well as it would have been were the = overload control signaling intact. The language in req 17 is close to = this point I think. How about we barrow that language? >=20 > REQ 21: In cases where a network node fails, is so overloaded that > it cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > congestion. The mechanism MUST result > in at least as much useful throughput as would have = resulted > if the overload control signaling were present. >=20 >=20 > This may imply the actions you mention, as so other requirements = around functioning in environments with nodes that do, and do not = support the mechanism, and fairness in that case. Overload can be = mitigated somewhat without overload control signaling, but that is not = sufficient to handle issues that are occurring on networks now. A good = bit of the front matter in the draft discusses this point. >=20 > It seems to me that if overload signaling is worthwhile, it must be = because it increases useful throughput (at least in some cases). > So I would expect that useful throughput without overload procedures = <=3D useful throughput with only local overload procedures <=3D useful = throughput with explicit signaling. Hence I would expect something more = like this: >=20 > ALT REQ 21: In cases where a network node fails, is so overloaded = that > it cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > congestion. In this case, actions based on local metrics = at the affected > or adjacent nodes may still provide some benefit. > The mechanism MUST result in at least as much useful = throughput as > if the affected nodes did not implement the mechanism. > The mechanism SHOULD result in more useful throughput than = if none > of the nodes implemented the mechanism. >=20 > Does that make sense? Or have I misunderstood completely? I think this shouldn't presuppose actions based on local metrics. It is = possible for the mechanism to do other things such as using other paths = to communicate information. That said, if there truly is no path to = communicate overload information, the overload mechanism can't really do = more than could be done now, in its absence. So I'm not sure the SHOULD = on the end would add anything. [...] >=20 >=20 > =20 >=20 >>=20 >> REQ 33: "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.": = this wording seems to imply that the mechanism must support overload = specification of arbitrary granularity, with a corresponding increase in = the complexity required on implementations. Even supporting "Diameter = session" could force a node to maintain session state when it is = otherwise not required (more an issue for Agents than end nodes), at a = corresponding increase in the cost and complexity of that node. Is = there anything to be concerned about here? Or is REQ 13 sufficient to = limit complexity? >=20 > I think req 13 probably covers this. I understand your concern = though, and share it. There is potential for significant complexity. = There have been a lot of comments on this point and I think there will = be a fair amount of thinking going into appropriate scoping of overload = control information in ways that balance work imposed on nodes with = capacity left on the table. Perhaps adding the word "unreasonably" in = between "without" and "forcing" would make folks feel more comfortable = that the necessary wiggle room is here for the mechanism specifiers. >=20 > That works. okay, I think we can add that to the todo list. [...] --Apple-Mail=_9962F381-6F21-4B2A-8E40-DDBC4054202C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Andrew,

comments = inline.

Thanks,

Eric

On Feb 20, 2013, at 13:29 , Andrew = Booth <lists.abooth@gmail.com> = wrote:

Hi Eric,

Sorry for the = delay, comments inline.

On Wed, Feb 20, 2013 at 11:12 AM, Andrew Booth = <abooth@pt.com> wrote:

-----Forwarded by Andrew Booth/PTI on = 02/20/2013 11:10AM -----
To: Andrew Booth <abooth@pt.com>
From: Eric McMurry <emcmurry@computer.org>
Date: 02/16/2013 12:55PM
Cc: dime@ietf.org, ben@nostrum.com
Subject: Re: = draft-ietf-dime-overload-reqs-03: some REQ comments and questions

Hi Andrew,

Sorry for the delay. Please see inline.
=
Thanks,

Eric

On Feb 4, 2013, at 23:13 , Andrew Booth < abooth@pt.com> wrote:

=

[...]

=

REQ = 7: query: Does this requirement imply that the proposed mechanism must = define one or more options for shedding load (as opposed to simply = requesting the clients to slow down)? Is it accurate to say that = processing TLS to get at the Diameter message may be a substantial part = of the message processing time, so a node may have limited ability to = distinguish between Diameter messages when shedding load? This = query applies to REQ 22 also.

I don't think this = requirement implies that there be multiple algorithms, but that is = called out elsewhere (at least the ability to add = them).

I think my question was poorly = phrased, but perhaps it is not relevant anyway.

To me there is a = difference between shedding work locally (returning errors, throttling = inbound messages, etc) vs sending load information to a peer who can = reduce the amount they send. I wasn't clear which version of = "shedding work" was referred to by REQ 7.

Should the mechanism provide a way for an overloaded = server to shed work locally? Or is that up to the mechanism? = Both the existing proposals (as far as I can tell) only specify the = behavior of a node that is sending a request; one of the proposals = additionally specifies an error code that could potentially be used by a = server, but no such procedures are specified (again, unless I missed = something).

I = don't think the requirements are specific on this point. A = mechanism could use local actions as well as remote requests for = overload mitigation. The mechanism has to support the remote = requests at a minimum = though.

[...]

=

REQ 20: does = "actual overload" deserve more clarification? For example, would = any or all of the following would represent "actual overload": CPU = usage, a deep send queue, messages incoming at an unexpectedly high = rate? Or is this something that would be defined by the proposed = mechanism? Or have I misunderstood completely?

the word actual may not = actually add anything here. All of the things you mentioned could = be causes of overload. I think the intent though is that existing = Diameter errors not be overloaded to be used for overload. Any = overload control mechanism needs to be clear about what is being = communicated.

Ok. I'm fine = with leaving it as it is, or removing "actual".

Aside: I'm left = wondering though whether the wording of this requirement prevents = overload signaling from being used by an agent to signal unavailability = of a server via that agent. Allowing node unavailability to be = signaled as overload could have some nice = benefits.

That= is certainly not the intent. I can see where your comment comes = from. Do others think we should change the wording = here?

REQ 21: Does = this imply that a node must be able to deduce overload of a peer or = indirectly accessible node based on local metrics only (response time, = send queue depth, etc)? Since "The mechanism MUST properly = function in these cases", does that require that explicit messaging is = unnecessary?

perhaps "properly = function" should be stated differently. The intent here is that = the mechanism not break things in this case and that the overload is = handled at least as well as it would have been were the overload control = signaling intact. The language in req 17 is close to this point I = think. How about we barrow that language?

REQ 21: In cases where a network node = fails, is so overloaded that

it cannot process = messages, or cannot communicate due to a

network failure, it may = not be able to provide explicit

indications of the nature = of the failure or its levels of

congestion. The = mechanism MUST result

in at least as much = useful throughput as would have resulted

if the overload control = signaling were present.

This may imply the actions you = mention, as so other requirements around functioning in environments = with nodes that do, and do not support the mechanism, and fairness in = that case. Overload can be mitigated somewhat without overload = control signaling, but that is not sufficient to handle issues that are = occurring on networks now. A good bit of the front matter in the = draft discusses this point.

It seems to me that if overload = signaling is worthwhile, it must be because it increases useful = throughput (at least in some cases).
So I would expect that useful throughput without overload procedures = <=3D useful throughput with only local overload procedures <=3D = useful throughput with explicit signaling. Hence I would expect = something more like this:

   ALT REQ 21: In cases where a network node fails, = is so overloaded = that
           = it cannot process messages, or cannot communicate due to = a
            = network failure, it may not be able to provide explicit
            = indications of the nature of the failure or its levels = of
            = congestion. In this case, actions based on local metrics at the = affected
          &n= bsp; or adjacent nodes may still provide some benefit.
            The = mechanism MUST result in at least as much useful throughput as
= if the affected nodes did not = implement the = mechanism.
          = The mechanism SHOULD result in more useful throughput than if = none
            of = the nodes implemented the mechanism.

Does that make sense? = Or have I misunderstood = completely?

I = think this shouldn't presuppose actions based on local metrics. It = is possible for the mechanism to do other things such as using other = paths to communicate information. That said, if there truly is no = path to communicate overload information, the overload mechanism can't = really do more than could be done now, in its absence. So I'm not = sure the SHOULD on the end would add = anything.

[...]

=

REQ 33: = "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.": = this wording seems to imply that the mechanism must support overload = specification of arbitrary granularity, with a corresponding increase in = the complexity required on implementations. Even supporting = "Diameter session" could force a node to maintain session state when it = is otherwise not required (more an issue for Agents than end nodes), at = a corresponding increase in the cost and complexity of that node. = Is there anything to be concerned about here? Or is REQ 13 = sufficient to limit complexity?

I think req 13 = probably covers this. I understand your concern though, and share = it. There is potential for significant complexity. There = have been a lot of comments on this point and I think there will be a = fair amount of thinking going into appropriate scoping of overload = control information in ways that balance work imposed on nodes with = capacity left on the table. Perhaps adding the word "unreasonably" in = between "without" and "forcing" would make folks feel more comfortable = that the necessary wiggle room is here for the mechanism = specifiers.

That = works.

okay, = I think we can add that to the todo = list.

[...]

= --Apple-Mail=_9962F381-6F21-4B2A-8E40-DDBC4054202C-- From lists.abooth@gmail.com Thu Feb 21 11:14:49 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F5B21F8EF9 for ; Thu, 21 Feb 2013 11:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIMMEo25pbjB for ; Thu, 21 Feb 2013 11:14:48 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6976321F8F35 for ; Thu, 21 Feb 2013 11:14:48 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id 6so4483854qea.24 for ; Thu, 21 Feb 2013 11:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cXmcVWkKR7GDjLg5RtazmKpVrHHrvDRyp5n5MhlqV9E=; b=clm2NhsVaLY8tWa6rko/SJ2FmpmnRvzgy21fYEbaA5KikYRKy3hyzGpQa5Jp78uk/F G/wWyrhT56xa2MN4jLxdr+dLmSTXLksm6X2CjuSZKAqruIlwsjVsZF6oatkYP+O1RJdF cF9bB21aZbyPB4pPBhGW2zumK7XeL1zryCba8/RgNkzBK27guaVvxYLop5MrlLzoDFsv bA6g+VI3AKaL1HPr3b4shSeZRy9l+aIbFvlbK+13a/Kb0f6xDwn+Yx231Ap5FFQrQaVd cY4ZCIlt/TN5l91WaxiWAreX8Y9TwG5tvbGwltq1AXaQANCsdgFxEEGHslSzlvj0hUfh yeEA== MIME-Version: 1.0 X-Received: by 10.49.2.7 with SMTP id 7mr1176558qeq.45.1361474087951; Thu, 21 Feb 2013 11:14:47 -0800 (PST) Received: by 10.49.63.163 with HTTP; Thu, 21 Feb 2013 11:14:47 -0800 (PST) In-Reply-To: References:

Date: Thu, 21 Feb 2013 14:14:47 -0500 Message-ID: From: Andrew Booth To: Eric McMurry Content-Type: multipart/alternative; boundary=047d7b6785fc621d4104d640e3d8 Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:14:49 -0000 --047d7b6785fc621d4104d640e3d8 Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, Comments inline. Thanks, Andrew On Wed, Feb 20, 2013 at 4:45 PM, Eric McMurry wrote: > Hi Andrew, > > comments inline. > > Thanks, > > Eric > > [...] >> >> REQ 21: Does this imply that a node must be able to deduce overload of a >> peer or indirectly accessible node based on local metrics only (response >> time, send queue depth, etc)? Since "The mechanism MUST properly function >> in these cases", does that require that explicit messaging is unnecessary? >> >> >> perhaps "properly function" should be stated differently. The intent here >> is that the mechanism not break things in this case and that the overload is >> handled at least as well as it would have been were the overload control >> signaling intact. The language in req 17 is close to this point I think. >> How about we barrow that language? >> >> REQ 21: In cases where a network node fails, is so overloaded that >> it cannot process messages, or cannot communicate due to a >> network failure, it may not be able to provide explicit >> indications of the nature of the failure or its levels of >> congestion. The mechanism MUST result >> in at least as much useful throughput as would have resulted >> if the overload control signaling were present. >> >> >> This may imply the actions you mention, as so other requirements around >> functioning in environments with nodes that do, and do not support the >> mechanism, and fairness in that case. Overload can be mitigated somewhat >> without overload control signaling, but that is not sufficient to handle >> issues that are occurring on networks now. A good bit of the front matter >> in the draft discusses this point. > > > It seems to me that if overload signaling is worthwhile, it must be because > it increases useful throughput (at least in some cases). > So I would expect that useful throughput without overload procedures <= > useful throughput with only local overload procedures <= useful throughput > with explicit signaling. Hence I would expect something more like this: > > ALT REQ 21: In cases where a network node fails, is so overloaded that > it cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > congestion. In this case, actions based on local metrics at the > affected > or adjacent nodes may still provide some benefit. > The mechanism MUST result in at least as much useful throughput > as > if the affected nodes did not implement the mechanism. > The mechanism SHOULD result in more useful throughput than if > none > of the nodes implemented the mechanism. > > Does that make sense? Or have I misunderstood completely? > > > I think this shouldn't presuppose actions based on local metrics. It is > possible for the mechanism to do other things such as using other paths to > communicate information. That said, if there truly is no path to > communicate overload information, the overload mechanism can't really do > more than could be done now, in its absence. So I'm not sure the SHOULD on > the end would add anything. > I'd be ok with simply removing the mention of local metrics and the SHOULD. However, that is somewhat weaker than what you suggested in the REQ 21 above. On the other hand, REQ 21 above confused me a bit on transitional issues (the time between when the node fails and others find out about it, especially if the adjacent nodes do not support the mechanism and can't signal others on behalf of the failed node). Does this come closer to capturing the intent of REQ 21, while satisfying the transitional issues? Or have I misunderstood the intent? ALT REQ 21: In cases where a network node X fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of congestion. In this case, the mechanism MUST result in at least as much useful throughput as if none of the nodes implemented the mechanism. Also, if all relevant nodes support the mechanism, and once sufficient nodes have discovered that X has become unavailable, the mechanism MUST result in at least as much useful throughput as would have resulted if X had successfully signaled complete overload. > [...] > --047d7b6785fc621d4104d640e3d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Eric,

Comments inline.

Thanks,
Andrew

On Wed, Fe= b 20, 2013 at 4:45 PM, Eric McMurry <emcmurry@computer.org> wrote:
> Hi Andrew,
>
&g= t; comments inline.
>
> Thanks,
>
> Eric
>
> [...]
>>=
>> REQ 21: Does this imply that a node must be able to deduce ove= rload of a
>> peer or indirectly accessible node based on local me= trics only (response
>> time, send queue depth, etc)? =A0Since "The mechanism MUST pr= operly function
>> in these cases", does that require that ex= plicit messaging is unnecessary?
>>
>>
>> perhap= s "properly function" should be stated differently. =A0The intent= here
>> is that the mechanism not break things in this case and that the o= verload is
>> handled at least as well as it would have been were = the overload control
>> signaling intact. =A0The language in req 1= 7 is close to this point I think.
>> How about we barrow that language?
>>
>> REQ 21:= =A0In cases where a network node fails, is so overloaded that
>> = =A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot communicate d= ue to a
>> =A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able to pro= vide explicit
>> =A0 =A0 =A0 =A0 =A0 =A0 indications of the nature= of the failure or its levels of
>> =A0 =A0 =A0 =A0 =A0 =A0 conges= tion. =A0The mechanism MUST result
>> =A0 =A0 =A0 =A0 =A0 =A0 in at least as much useful throughput as w= ould have resulted
>> =A0 =A0 =A0 =A0 =A0 =A0 if the overload cont= rol signaling were present.
>>
>>
>> This may im= ply the actions you mention, as so other requirements around
>> functioning in environments with nodes that do, and do not support= the
>> mechanism, and fairness in that case. =A0Overload can be m= itigated somewhat
>> without overload control signaling, but that = is not sufficient to handle
>> issues that are occurring on networks now. =A0A good bit of the fr= ont matter
>> in the draft discusses this point.
>
>> It seems to me that if overload signaling is worthwhile, it must be = because
> it increases useful throughput (at least in some cases).
> So I = would expect that useful throughput without overload procedures <=3D
= > useful throughput with only local overload procedures <=3D useful t= hroughput
> with explicit signaling. =A0Hence I would expect something more like t= his:
>
> =A0 =A0ALT REQ 21: =A0In cases where a network node fa= ils, is so overloaded that
> =A0 =A0 =A0 =A0 =A0 =A0 it cannot proces= s messages, or cannot communicate due to a
> =A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able to provide= explicit
> =A0 =A0 =A0 =A0 =A0 =A0 indications of the nature of the = failure or its levels of
> =A0 =A0 =A0 =A0 =A0 =A0 congestion. =A0In = this case, actions based on local metrics at the
> affected
> =A0 =A0 =A0 =A0 =A0 =A0 or adjacent nodes may still p= rovide some benefit.
> =A0 =A0 =A0 =A0 =A0 =A0 The mechanism MUST res= ult in at least as much useful throughput
> as
> =A0 =A0 =A0 = =A0 =A0 =A0 if the affected nodes did not implement the mechanism.
> =A0 =A0 =A0 =A0 =A0 =A0 The mechanism SHOULD result in more useful thr= oughput than if
> none
> =A0 =A0 =A0 =A0 =A0 =A0 of the nodes i= mplemented the mechanism.
>
> Does that make sense? =A0Or have = I misunderstood completely?
>
>
> I think this shouldn't presuppose actions based on= local metrics. =A0It is
> possible for the mechanism to do other thi= ngs such as using other paths to
> communicate information. =A0That s= aid, if there truly is no path to
> communicate overload information, the overload mechanism can't rea= lly do
> more than could be done now, in its absence. =A0So I'm n= ot sure the SHOULD on
> the end would add anything.
>

I'd be ok with simply removing the mention of local metrics and the SHO= ULD.=A0 However, that is somewhat weaker than what you suggested in the REQ= 21 above.=A0 On the other hand, REQ 21 above confused me a bit on transiti= onal issues (the time between when the node fails and others find out about= it, especially if the adjacent nodes do not support the mechanism and can&= #39;t signal others on behalf of the failed node).
Does this come closer to capturing the intent of REQ 21, while satisfying t= he transitional issues?=A0 Or have I misunderstood the intent?

ALT R= EQ 21: In cases where a network node X fails, is so overloaded that
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot c= ommunicate due to a
=A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 network failure, it may not= be able to provide explicit
=A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0= =A0=A0 indications of the nature of the failure or its levels of
=A0 =A0= =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 congestion.
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In this case, the mechanism MUST= result in at least as much
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 useful throughput= as if none of the nodes implemented the mechanism.
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Also, if all relevant nodes support= the mechanism, and once sufficient nodes
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 have discovered that X has become unavailable, = the mechanism MUST
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 result in at leas= t as much useful throughput as would have resulted if X
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 had successfully signaled comple= te overload.

> [...]
>

--047d7b6785fc621d4104d640e3d8-- From lists.abooth@gmail.com Thu Feb 21 11:16:15 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951FD21F8F42 for ; Thu, 21 Feb 2013 11:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VED+VxAlvp+i for ; Thu, 21 Feb 2013 11:16:15 -0800 (PST) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id CCFD321F8F40 for ; Thu, 21 Feb 2013 11:16:14 -0800 (PST) Received: by mail-qe0-f41.google.com with SMTP id 7so4579692qeb.28 for ; Thu, 21 Feb 2013 11:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RHHgaQo5bl2ZvOgVWNRHw32AhIAh/ckNdpmJdIoHNWM=; b=XDIvy24j1DZoOcYM37fSBvobY2jdX/5Hj7BSq7+gUsHmMTzlG2BO6mHWwLxyn1IaFK 3IOKEr1/Wq65en+HCHlb97DPLnY9XZNdUG6zMOX8b3D2NjA36RzhCNRU7USwPu2kXtj6 1NN/mF/6uNnHJQKaFYG41Dxz8lBZRpaGjLHwY+k63TRG5uyY78YTHoxmKvrw9eGvkeEn SoN8vH6hNTNZ9+XduSrGNeMnJW3yCxsQnbG+J1qxW4aG65zqKy8rHpQGFj9xyNiZm8sd VvfghZ/3IV6BbGnUzw1SBygK4mbFNNa4sMPWJUmtDtV8NVhYSL4YZZS4jWthrLD5Inq1 TlkA== MIME-Version: 1.0 X-Received: by 10.224.186.83 with SMTP id cr19mr11635821qab.51.1361474174291; Thu, 21 Feb 2013 11:16:14 -0800 (PST) Received: by 10.49.63.163 with HTTP; Thu, 21 Feb 2013 11:16:14 -0800 (PST) In-Reply-To: References:

Date: Thu, 21 Feb 2013 14:16:14 -0500 Message-ID: From: Andrew Booth To: Ben Campbell Content-Type: multipart/alternative; boundary=20cf30363f75878f5804d640e806 Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 10 on end of overload condition X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:16:15 -0000 --20cf30363f75878f5804d640e806 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 20, 2013 at 2:44 PM, Ben Campbell wrote: > > On Feb 20, 2013, at 1:38 PM, Eric McMurry wrote: > > > Req 10 reads: Consumers of overload state indications MUST be able to > > determine when the overload condition improves or ends. > > > > It has been pointed out that the term "overload state indications" may > imply aspects of implementation. In the rest of the document the more > generic "overload information" is generally used. I think it would make > sense to use that here as well. So Req 10 would read: > > > > Consumers of overload information MUST be able to > > determine when the overload condition improves or ends. > > WFM > Sounds good to me. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --20cf30363f75878f5804d640e806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 20, 2013 at 2:44 PM, Ben Cam= pbell <ben@nostrum.com> wrote:

On Feb 20, 2013, at 1:38 PM, Eric McMurry <emcmurry@computer.org> wrote:

> Req 10 reads: =A0Consumers of overload state indications MUST be able = to
> =A0 =A0 =A0 =A0 =A0 =A0determine when the overload condition improves = or ends.
>
> It has been pointed out that the term "overload state indications= " may imply aspects of implementation. =A0In the rest of the document = the more generic "overload information" is generally used. =A0I t= hink it would make sense to use that here as well. =A0So Req 10 would read:=
>
> =A0 Consumers of overload information MUST be able to
> =A0 =A0 =A0 =A0 =A0 =A0determine when the overload condition improves = or ends.

WFM

Sounds good to me.
=A0

___________________________________= ____________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--20cf30363f75878f5804d640e806-- From lists.abooth@gmail.com Thu Feb 21 11:23:09 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004CF21F8F67 for ; Thu, 21 Feb 2013 11:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkplRUAGQTU9 for ; Thu, 21 Feb 2013 11:23:05 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id C78EC21F8F64 for ; Thu, 21 Feb 2013 11:23:04 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id n41so3743021qco.35 for ; Thu, 21 Feb 2013 11:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=Pvk8BMzcEjCXpKRHmMDRo7iQ3TdtGxX9KOXIMjmoNQE=; b=goPYajYP2pcHX4q7MISjxgVhBcv43U0xV5nYS5XJZuitpGVCMUUB3VzlV40Q47j4og G+ZlAUJyDdi981E5msGSvwR0XeVeJM+iYiQF1OadfkVL5pE9fwopQt7FVdLTr3wRj4Mg fL2X+oY8niEp/uo3T3OWdvD1ixK/VcUaHYB8At9uSo/WuJ1frp/hXvBG15v7wBHp9G7M cdVbqWxI/7FXOksgAkIJXzgp7PxPwh7CzZ9KvwSaR7r1IX8S3jf/sx/uZdEA5gZOKUe0 1TEejJur/75I6Djp3T+s2v5ySMmZgStyQD+KoBm5KFUzO1lMAir4Y5i+H1ljo1w8wBeD H6Tw== MIME-Version: 1.0 X-Received: by 10.224.186.83 with SMTP id cr19mr11648538qab.51.1361474584370; Thu, 21 Feb 2013 11:23:04 -0800 (PST) Received: by 10.49.63.163 with HTTP; Thu, 21 Feb 2013 11:23:04 -0800 (PST) Date: Thu, 21 Feb 2013 14:23:04 -0500 Message-ID: From: Andrew Booth To: Eric McMurry Content-Type: text/plain; charset=ISO-8859-1 Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: answer/transport failure X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:23:09 -0000 Hi Eric, A while ago we discussed >> >> >> 4.1. Problems with Implicit Mechanism >> >> "Diameter treats the failure to receive an answer as a transport failure." >> >> I'm not clear on this... do you mean if you fail to receive a single answer? >> Or if a node is not providing any answers? Perhaps a spec reference would make this clearer? > > generally, it's lack of an answer to a WDR after timer Tw. Implementations may be more aggressive than this though. Ben, do you recall if we were talking about > something other than that here? Can we add a reference to the watchdog request? "Diameter treats the failure to receive an answer to a watchdog request as a transport failure."? Thanks for any info, Andrew From ben@nostrum.com Thu Feb 21 11:32:58 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5346D21F89C0 for ; Thu, 21 Feb 2013 11:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwRo1mgssP6b for ; Thu, 21 Feb 2013 11:32:58 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DC76C21F8984 for ; Thu, 21 Feb 2013 11:32:57 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1LJWlN0020929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 13:32:47 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ben Campbell In-Reply-To: Date: Thu, 21 Feb 2013 13:32:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andrew Booth X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: answer/transport failure X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:32:58 -0000 On Feb 21, 2013, at 1:23 PM, Andrew Booth = wrote: > Hi Eric, >=20 > A while ago we discussed >>>=20 >>>=20 >>> 4.1. Problems with Implicit Mechanism >>>=20 >>> "Diameter treats the failure to receive an answer as a transport = failure." >>>=20 >>> I'm not clear on this... do you mean if you fail to receive a = single answer? >>> Or if a node is not providing any answers? Perhaps a spec = reference would make this clearer? >>=20 >> generally, it's lack of an answer to a WDR after timer Tw. = Implementations may be more aggressive than this though. Ben, do you = recall if we were talking about > something other than that here? >=20 > Can we add a reference to the watchdog request? "Diameter treats the > failure to receive an answer to a watchdog request as a transport > failure."? DWR is part of the core Diameter protocol (RFC 6733). Do we need a = separate reference for that? From emcmurry@computer.org Thu Feb 21 11:35:35 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639AC21F8F25 for ; Thu, 21 Feb 2013 11:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yglJL6eVr1jv for ; Thu, 21 Feb 2013 11:35:34 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4745621F8F23 for ; Thu, 21 Feb 2013 11:35:34 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from

On Feb 21, 2013, at 13:14 , Andrew Booth = <lists.abooth@gmail.com> = wrote:

Hi Eric,

Comments = inline.

Thanks,
Andrew

On Wed, Feb 20, 2013 at 4:45 PM, = Eric McMurry <emcmurry@computer.org> = wrote:
> Hi Andrew,
>
> comments inline.
>
> Thanks,
>
> Eric
>
> = [...]
>>
>> REQ 21: Does this imply that a node must = be able to deduce overload of a
>> peer or indirectly = accessible node based on local metrics only (response
>> time, send queue depth, etc)? Since "The mechanism MUST = properly function
>> in these cases", does that require that = explicit messaging is unnecessary?
>>
>>
>> = perhaps "properly function" should be stated differently. The = intent here
>> is that the mechanism not break things in this case and that = the overload is
>> handled at least as well as it would have = been were the overload control
>> signaling intact. The = language in req 17 is close to this point I think.
>> How about we barrow that language?
>>
>> REQ = 21: In cases where a network node fails, is so overloaded = that
>> it cannot = process messages, or cannot communicate due to a
>> network failure, it = may not be able to provide explicit
>> = indications of the nature of the failure or its = levels of
>> = congestion. The mechanism MUST result
>> in at least as much = useful throughput as would have resulted
>> = if the overload control signaling were = present.
>>
>>
>> This may imply the actions = you mention, as so other requirements around
>> functioning in environments with nodes that do, and do not = support the
>> mechanism, and fairness in that case. = Overload can be mitigated somewhat
>> without overload = control signaling, but that is not sufficient to handle
>> issues that are occurring on networks now. A good bit of = the front matter
>> in the draft discusses this = point.
>
>
> It seems to me that if overload signaling = is worthwhile, it must be because
> it increases useful throughput (at least in some cases).
> So = I would expect that useful throughput without overload procedures = <=3D
> useful throughput with only local overload procedures = <=3D useful throughput
> with explicit signaling. Hence I would expect something more = like this:
>
> ALT REQ 21: In cases where = a network node fails, is so overloaded that
> = it cannot process messages, or cannot communicate = due to a
> network failure, it may = not be able to provide explicit
> = indications of the nature of the failure or its levels = of
> congestion. = In this case, actions based on local metrics at the
> affected
> or = adjacent nodes may still provide some benefit.
> = The mechanism MUST result in at least as = much useful throughput
> as
> = if the affected nodes did not implement the mechanism.
> The mechanism SHOULD = result in more useful throughput than if
> none
> = of the nodes implemented the = mechanism.
>
> Does that make sense? Or have I = misunderstood completely?
>
>
> I think this shouldn't presuppose actions based on = local metrics. It is
> possible for the mechanism to do = other things such as using other paths to
> communicate = information. That said, if there truly is no path to
> communicate overload information, the overload mechanism can't = really do
> more than could be done now, in its absence. So = I'm not sure the SHOULD on
> the end would add = anything.
>

I'd be ok with simply removing the mention of local metrics and the = SHOULD. However, that is somewhat weaker than what you suggested = in the REQ 21 above. On the other hand, REQ 21 above confused me a = bit on transitional issues (the time between when the node fails and = others find out about it, especially if the adjacent nodes do not = support the mechanism and can't signal others on behalf of the failed = node).
Does this come closer to capturing the intent of REQ 21, while = satisfying the transitional issues? Or have I misunderstood the = intent?

ALT REQ 21: In cases where a network node X fails, is so = overloaded that
= it cannot process messages, or cannot communicate = due to a
=           network failure, = it may not be able to provide explicit
=           = indications of the nature of the failure or its levels of
= =             = congestion.
          = ;          In this case, = the mechanism MUST result in at least as much
=             &n= bsp;       useful throughput as if none of = the nodes implemented the = mechanism.
          =           Also, if all = relevant nodes support the mechanism, and once sufficient = nodes
           = ;         have discovered that X = has become unavailable, the mechanism MUST
=             &n= bsp;       result in at least as much = useful throughput as would have resulted if = X
           &nb= sp;        had successfully signaled = complete overload.

> [...]
>

= --Apple-Mail=_E18FF14B-6567-4E90-BE7B-FD7EE47C6085-- From lists.abooth@gmail.com Thu Feb 21 12:15:34 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739B221F8F6E for ; Thu, 21 Feb 2013 12:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndLAGiooFaEE for ; Thu, 21 Feb 2013 12:15:33 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 398E621F8F6A for ; Thu, 21 Feb 2013 12:15:33 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id 3so4550161qea.35 for ; Thu, 21 Feb 2013 12:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Fg3kLXSkyQzppJiQxnlSWXkgNJ6gZEvm8fTwKam3kvA=; b=vpIVk2fLdGMibNmEKFNzF7XSRtH0zaEbUgWmNumQmOe9cRtNIyD1D20QcUwi3bPakL 6T1r3ixznUajC4eNyowp/2PEtpGLPSbmenJhdb63/3nRVtySAErIgdHG8Srje7ox987x GY+EYNqolqNl4319hsjCzpT/R5T9z3IGZEX1Jy5Y+NH4fV8Dp51EiB4iz90xkpZve//l eX12/HnBNo8ERfmhwZ8jH20tuUL6hXaVBWmgrdb1U9NcqdP4m2cMbWDPRbwws/A2VA4/ bk/9U3Y5z0qktoENy5S0qGqKRL4EkaMBPVAaR1IVz06NtKIJ8P/xQJ2GtfTsnS6VTYOd 3XoQ== MIME-Version: 1.0 X-Received: by 10.224.173.147 with SMTP id p19mr12106794qaz.78.1361477732768; Thu, 21 Feb 2013 12:15:32 -0800 (PST) Received: by 10.49.63.163 with HTTP; Thu, 21 Feb 2013 12:15:32 -0800 (PST) In-Reply-To: <5CA501AC-1BF9-420F-96E3-938304065C6D@computer.org> References:

<5CA501AC-1BF9-420F-96E3-938304065C6D@computer.org> Date: Thu, 21 Feb 2013 15:15:32 -0500 Message-ID: From: Andrew Booth To: Eric McMurry Content-Type: multipart/alternative; boundary=485b397dd77ba19b8704d641bcfc Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:15:34 -0000 --485b397dd77ba19b8704d641bcfc Content-Type: text/plain; charset=ISO-8859-1 When I re-read the thread, I was worried that I'd neutered REQ 21 away from what you originally intended. Sounds like I'm just over-complicating things. Let's take a step back. What is your current favorite candidate for REQ 21? Andrew On Thu, Feb 21, 2013 at 2:35 PM, Eric McMurry wrote: > Hi Andrew, > > I'm a bit lost on what you are wanting to add here. The gist of this > requirement is that the mechanism shouldn't make things worse in this > situation, and no more than that. > > I don't think we can strengthen that to the point that the mechanism will > work the same in cases where signaling is not possible as in cases where it > is, and requiring that it find ways to route overload signaling information > around the issues is probably saying too much about the implementation. > > I'm also not understanding your comment on transitional issues and how it > relates here. > > Sorry, I'm a bit slow today. you'll have to bear with me :-) > > Thanks, > > Eric > > > On Feb 21, 2013, at 13:14 , Andrew Booth wrote: > > Hi Eric, > > Comments inline. > > Thanks, > Andrew > > On Wed, Feb 20, 2013 at 4:45 PM, Eric McMurry > wrote: > > Hi Andrew, > > > > comments inline. > > > > Thanks, > > > > Eric > > > > [...] > >> > >> REQ 21: Does this imply that a node must be able to deduce overload of a > >> peer or indirectly accessible node based on local metrics only (response > >> time, send queue depth, etc)? Since "The mechanism MUST properly > function > >> in these cases", does that require that explicit messaging is > unnecessary? > >> > >> > >> perhaps "properly function" should be stated differently. The intent > here > >> is that the mechanism not break things in this case and that the > overload is > >> handled at least as well as it would have been were the overload control > >> signaling intact. The language in req 17 is close to this point I > think. > >> How about we barrow that language? > >> > >> REQ 21: In cases where a network node fails, is so overloaded that > >> it cannot process messages, or cannot communicate due to a > >> network failure, it may not be able to provide explicit > >> indications of the nature of the failure or its levels of > >> congestion. The mechanism MUST result > >> in at least as much useful throughput as would have resulted > >> if the overload control signaling were present. > >> > >> > >> This may imply the actions you mention, as so other requirements around > >> functioning in environments with nodes that do, and do not support the > >> mechanism, and fairness in that case. Overload can be mitigated > somewhat > >> without overload control signaling, but that is not sufficient to handle > >> issues that are occurring on networks now. A good bit of the front > matter > >> in the draft discusses this point. > > > > > > It seems to me that if overload signaling is worthwhile, it must be > because > > it increases useful throughput (at least in some cases). > > So I would expect that useful throughput without overload procedures <= > > useful throughput with only local overload procedures <= useful > throughput > > with explicit signaling. Hence I would expect something more like this: > > > > ALT REQ 21: In cases where a network node fails, is so overloaded > that > > it cannot process messages, or cannot communicate due to a > > network failure, it may not be able to provide explicit > > indications of the nature of the failure or its levels of > > congestion. In this case, actions based on local metrics at > the > > affected > > or adjacent nodes may still provide some benefit. > > The mechanism MUST result in at least as much useful > throughput > > as > > if the affected nodes did not implement the mechanism. > > The mechanism SHOULD result in more useful throughput than if > > none > > of the nodes implemented the mechanism. > > > > Does that make sense? Or have I misunderstood completely? > > > > > > I think this shouldn't presuppose actions based on local metrics. It is > > possible for the mechanism to do other things such as using other paths > to > > communicate information. That said, if there truly is no path to > > communicate overload information, the overload mechanism can't really do > > more than could be done now, in its absence. So I'm not sure the SHOULD > on > > the end would add anything. > > > > I'd be ok with simply removing the mention of local metrics and the > SHOULD. However, that is somewhat weaker than what you suggested in the > REQ 21 above. On the other hand, REQ 21 above confused me a bit on > transitional issues (the time between when the node fails and others find > out about it, especially if the adjacent nodes do not support the mechanism > and can't signal others on behalf of the failed node). > Does this come closer to capturing the intent of REQ 21, while satisfying > the transitional issues? Or have I misunderstood the intent? > > ALT REQ 21: In cases where a network node X fails, is so overloaded that > it cannot process messages, or cannot communicate due > to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels > of > congestion. > In this case, the mechanism MUST result in at least as > much > useful throughput as if none of the nodes implemented > the mechanism. > Also, if all relevant nodes support the mechanism, and > once sufficient nodes > have discovered that X has become unavailable, the > mechanism MUST > result in at least as much useful throughput as would > have resulted if X > had successfully signaled complete overload. > > > > [...] > > > > > > --485b397dd77ba19b8704d641bcfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When I re-read the thread, I was worried that I'd neutered REQ 21 away= from what you originally intended.
Sounds like I'm just over-compli= cating things.=A0 Let's take a step back.

What is your current f= avorite candidate for REQ 21?

Andrew

On Thu, Feb 21, 2013 at 2:35 P= M, Eric McMurry <emcmurry@computer.org> wrote:

Hi Andrew,

I'm a= bit lost on what you are wanting to add here. =A0The gist of this requirem= ent is that the mechanism shouldn't make things worse in this situation= , and no more than that.

=
=A0

I don't think we can strengthe= n that to the point that the mechanism will work the same in cases where si= gnaling is not possible as in cases where it is, and requiring that it find= ways to route overload signaling information around the issues is probably= saying too much about the implementation.

I'm also not understanding your comment on transiti= onal issues and how it relates here.

Sorry, I'= m a bit slow today. =A0you'll have to bear with me :-)

Thanks,

Eric

On Feb 21, 2013, at 13:14 , Andrew Boot= h <lists.abo= oth@gmail.com> wrote:

Hi Eric,

Comments inline.

Thank= s,
Andrew

On Wed, Feb 20, 2013 at 4:45 PM, Eric McMurry <emcmurry@computer.org= > wrote:
> Hi Andrew,
>
> comments inline.
>
> Thanks,
>
> Eric
>
> [...]
>>=
>> REQ 21: Does this imply that a node must be able to deduce ove= rload of a
>> peer or indirectly accessible node based on local me= trics only (response
>> time, send queue depth, etc)? =A0Since "The mechanism MUST pr= operly function
>> in these cases", does that require that ex= plicit messaging is unnecessary?
>>
>>
>> perhap= s "properly function" should be stated differently. =A0The intent= here
>> is that the mechanism not break things in this case and that the o= verload is
>> handled at least as well as it would have been were = the overload control
>> signaling intact. =A0The language in req 1= 7 is close to this point I think.
>> How about we barrow that language?
>>
>> REQ 21:= =A0In cases where a network node fails, is so overloaded that
>> = =A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot communicate d= ue to a
>> =A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able to pro= vide explicit
>> =A0 =A0 =A0 =A0 =A0 =A0 indications of the nature= of the failure or its levels of
>> =A0 =A0 =A0 =A0 =A0 =A0 conges= tion. =A0The mechanism MUST result
>> =A0 =A0 =A0 =A0 =A0 =A0 in at least as much useful throughput as w= ould have resulted
>> =A0 =A0 =A0 =A0 =A0 =A0 if the overload cont= rol signaling were present.
>>
>>
>> This may im= ply the actions you mention, as so other requirements around
>> functioning in environments with nodes that do, and do not support= the
>> mechanism, and fairness in that case. =A0Overload can be m= itigated somewhat
>> without overload control signaling, but that = is not sufficient to handle
>> issues that are occurring on networks now. =A0A good bit of the fr= ont matter
>> in the draft discusses this point.
>
>> It seems to me that if overload signaling is worthwhile, it must be = because
> it increases useful throughput (at least in some cases).
> So I = would expect that useful throughput without overload procedures <=3D
= > useful throughput with only local overload procedures <=3D useful t= hroughput
> with explicit signaling. =A0Hence I would expect something more like t= his:
>
> =A0 =A0ALT REQ 21: =A0In cases where a network node fa= ils, is so overloaded that
> =A0 =A0 =A0 =A0 =A0 =A0 it cannot proces= s messages, or cannot communicate due to a
> =A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able to provide= explicit
> =A0 =A0 =A0 =A0 =A0 =A0 indications of the nature of the = failure or its levels of
> =A0 =A0 =A0 =A0 =A0 =A0 congestion. =A0In = this case, actions based on local metrics at the
> affected
> =A0 =A0 =A0 =A0 =A0 =A0 or adjacent nodes may still p= rovide some benefit.
> =A0 =A0 =A0 =A0 =A0 =A0 The mechanism MUST res= ult in at least as much useful throughput
> as
> =A0 =A0 =A0 = =A0 =A0 =A0 if the affected nodes did not implement the mechanism.
> =A0 =A0 =A0 =A0 =A0 =A0 The mechanism SHOULD result in more useful thr= oughput than if
> none
> =A0 =A0 =A0 =A0 =A0 =A0 of the nodes i= mplemented the mechanism.
>
> Does that make sense? =A0Or have = I misunderstood completely?
>
>
> I think this shouldn't presuppose actions based on= local metrics. =A0It is
> possible for the mechanism to do other thi= ngs such as using other paths to
> communicate information. =A0That s= aid, if there truly is no path to
> communicate overload information, the overload mechanism can't rea= lly do
> more than could be done now, in its absence. =A0So I'm n= ot sure the SHOULD on
> the end would add anything.
>

I'd be ok with simply removing the mention of local metrics and the SHO= ULD.=A0 However, that is somewhat weaker than what you suggested in the REQ= 21 above.=A0 On the other hand, REQ 21 above confused me a bit on transiti= onal issues (the time between when the node fails and others find out about= it, especially if the adjacent nodes do not support the mechanism and can&= #39;t signal others on behalf of the failed node).
Does this come closer to capturing the intent of REQ 21, while satisfying t= he transitional issues?=A0 Or have I misunderstood the intent?

ALT R= EQ 21: In cases where a network node X fails, is so overloaded that
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot c= ommunicate due to a
=A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 network failure, it may not= be able to provide explicit
=A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0= =A0=A0 indications of the nature of the failure or its levels of
=A0 =A0= =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 congestion.
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In this case, the mechanism MUST= result in at least as much
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 useful throughput= as if none of the nodes implemented the mechanism.
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Also, if all relevant nodes support= the mechanism, and once sufficient nodes
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 have discovered that X has become unavailable, = the mechanism MUST
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 result in at leas= t as much useful throughput as would have resulted if X
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 had successfully signaled comple= te overload.

> [...]
>

--485b397dd77ba19b8704d641bcfc-- From emcmurry@computer.org Thu Feb 21 12:32:32 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2E521F8BE0 for ; Thu, 21 Feb 2013 12:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve8Q-cEhD6za for ; Thu, 21 Feb 2013 12:32:31 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9221F890D for ; Thu, 21 Feb 2013 12:32:31 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8cog-000Khp-U9; Thu, 21 Feb 2013 20:32:31 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id B2F7D1F55123; Thu, 21 Feb 2013 14:32:29 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/kvhJKKCtfT8pi0rYytuYKcv/noLIqvq8= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P2nenw6B0cR; Thu, 21 Feb 2013 14:32:29 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 5B2AA1F55112; Thu, 21 Feb 2013 14:32:29 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D384B27-C522-4F13-9DEF-3BFBFFD22640" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: Date: Thu, 21 Feb 2013 14:32:28 -0600 Message-Id: <63660CEB-5FBF-462D-AEAC-907F07B81586@computer.org> References:

<5CA501AC-1BF9-420F-96E3-938304065C6D@computer.org> To: Andrew Booth X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:32:32 -0000 --Apple-Mail=_7D384B27-C522-4F13-9DEF-3BFBFFD22640 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 okay. Here's what I have in my working copy of the 04 reqs: REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of congestion. The mechanism MUST result in at least as much useful throughput as would have resulted if the overload control signaling were present. This wasn't too far from the original, but I think the wording is more = clear. I think this was from the first or second round of our = conversation. thanks, Eric On Feb 21, 2013, at 14:15 , Andrew Booth wrote: > When I re-read the thread, I was worried that I'd neutered REQ 21 away = from what you originally intended. > Sounds like I'm just over-complicating things. Let's take a step = back. >=20 > What is your current favorite candidate for REQ 21? >=20 > Andrew >=20 > On Thu, Feb 21, 2013 at 2:35 PM, Eric McMurry = wrote: > Hi Andrew, >=20 > I'm a bit lost on what you are wanting to add here. The gist of this = requirement is that the mechanism shouldn't make things worse in this = situation, and no more than that. > =20 > I don't think we can strengthen that to the point that the mechanism = will work the same in cases where signaling is not possible as in cases = where it is, and requiring that it find ways to route overload signaling = information around the issues is probably saying too much about the = implementation. >=20 > I'm also not understanding your comment on transitional issues and how = it relates here. >=20 > Sorry, I'm a bit slow today. you'll have to bear with me :-) >=20 > Thanks, >=20 > Eric >=20 >=20 > On Feb 21, 2013, at 13:14 , Andrew Booth = wrote: >=20 >> Hi Eric, >>=20 >> Comments inline. >>=20 >> Thanks, >> Andrew >>=20 >> On Wed, Feb 20, 2013 at 4:45 PM, Eric McMurry = wrote: >> > Hi Andrew, >> > >> > comments inline. >> > >> > Thanks, >> > >> > Eric >> > >> > [...] >> >> >> >> REQ 21: Does this imply that a node must be able to deduce = overload of a >> >> peer or indirectly accessible node based on local metrics only = (response >> >> time, send queue depth, etc)? Since "The mechanism MUST properly = function >> >> in these cases", does that require that explicit messaging is = unnecessary? >> >> >> >> >> >> perhaps "properly function" should be stated differently. The = intent here >> >> is that the mechanism not break things in this case and that the = overload is >> >> handled at least as well as it would have been were the overload = control >> >> signaling intact. The language in req 17 is close to this point I = think.=20 >> >> How about we barrow that language? >> >> >> >> REQ 21: In cases where a network node fails, is so overloaded = that >> >> it cannot process messages, or cannot communicate due = to a >> >> network failure, it may not be able to provide = explicit >> >> indications of the nature of the failure or its levels = of >> >> congestion. The mechanism MUST result >> >> in at least as much useful throughput as would have = resulted >> >> if the overload control signaling were present. >> >> >> >> >> >> This may imply the actions you mention, as so other requirements = around >> >> functioning in environments with nodes that do, and do not support = the >> >> mechanism, and fairness in that case. Overload can be mitigated = somewhat >> >> without overload control signaling, but that is not sufficient to = handle >> >> issues that are occurring on networks now. A good bit of the = front matter >> >> in the draft discusses this point. >> > >> > >> > It seems to me that if overload signaling is worthwhile, it must be = because >> > it increases useful throughput (at least in some cases). >> > So I would expect that useful throughput without overload = procedures <=3D >> > useful throughput with only local overload procedures <=3D useful = throughput >> > with explicit signaling. Hence I would expect something more like = this: >> > >> > ALT REQ 21: In cases where a network node fails, is so = overloaded that >> > it cannot process messages, or cannot communicate due = to a >> > network failure, it may not be able to provide explicit >> > indications of the nature of the failure or its levels = of >> > congestion. In this case, actions based on local = metrics at the >> > affected >> > or adjacent nodes may still provide some benefit. >> > The mechanism MUST result in at least as much useful = throughput >> > as >> > if the affected nodes did not implement the mechanism. >> > The mechanism SHOULD result in more useful throughput = than if >> > none >> > of the nodes implemented the mechanism. >> > >> > Does that make sense? Or have I misunderstood completely? >> > >> > >> > I think this shouldn't presuppose actions based on local metrics. = It is >> > possible for the mechanism to do other things such as using other = paths to >> > communicate information. That said, if there truly is no path to >> > communicate overload information, the overload mechanism can't = really do >> > more than could be done now, in its absence. So I'm not sure the = SHOULD on >> > the end would add anything. >> > >>=20 >> I'd be ok with simply removing the mention of local metrics and the = SHOULD. However, that is somewhat weaker than what you suggested in the = REQ 21 above. On the other hand, REQ 21 above confused me a bit on = transitional issues (the time between when the node fails and others = find out about it, especially if the adjacent nodes do not support the = mechanism and can't signal others on behalf of the failed node). >> Does this come closer to capturing the intent of REQ 21, while = satisfying the transitional issues? Or have I misunderstood the intent? >>=20 >> ALT REQ 21: In cases where a network node X fails, is so overloaded = that >> it cannot process messages, or cannot communicate = due to a >> network failure, it may not be able to provide = explicit >> indications of the nature of the failure or its = levels of >> congestion. >> In this case, the mechanism MUST result in at = least as much >> useful throughput as if none of the nodes = implemented the mechanism. >> Also, if all relevant nodes support the = mechanism, and once sufficient nodes >> have discovered that X has become unavailable, = the mechanism MUST >> result in at least as much useful throughput as = would have resulted if X >> had successfully signaled complete overload. >>=20 >>=20 >> > [...] >> > >>=20 >>=20 >=20 >=20 --Apple-Mail=_7D384B27-C522-4F13-9DEF-3BFBFFD22640 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 okay. = Here's what I have in my working copy of the 04 = reqs:

REQ 21: In cases where a network = node fails, is so overloaded that

= it cannot process messages, or cannot communicate due to = a

network failure, = it may not be able to provide explicit

= indications of the nature of the failure or its = levels of

= congestion. The mechanism MUST result in at least as = much

useful = throughput as would have resulted if the overload

= control signaling were = present.

This wasn't too far from the = original, but I think the wording is more clear. I think this was = from the first or second round of our = conversation.

thanks,

Er= ic

On Feb 21, = 2013, at 14:15 , Andrew Booth <lists.abooth@gmail.com> = wrote:

When I re-read the thread, I was worried that I'd = neutered REQ 21 away from what you originally intended.
Sounds like = I'm just over-complicating things. Let's take a step = back.

What is your current favorite candidate for REQ 21?

Andrew

On Thu, Feb 21, 2013 at = 2:35 PM, Eric McMurry <emcmurry@computer.org> = wrote:

Hi Andrew,

I'm a = bit lost on what you are wanting to add here. The gist of this = requirement is that the mechanism shouldn't make things worse in this = situation, and no more than that.

I don't think we can strengthen = that to the point that the mechanism will work the same in cases where = signaling is not possible as in cases where it is, and requiring that it = find ways to route overload signaling information around the issues is = probably saying too much about the implementation.

I'm also not understanding your comment on = transitional issues and how it relates = here.

Sorry, I'm a bit slow today. you'll = have to bear with me :-)

Thanks,

Eric

On Feb 21, 2013, at 13:14 = , Andrew Booth <lists.abooth@gmail.com> wrote:

Hi Eric,

Comments = inline.

Thanks,
Andrew

On Wed, Feb 20, 2013 at 4:45 PM, = Eric McMurry <emcmurry@computer.org> wrote:
> Hi Andrew,
>
> comments inline.
>
> Thanks,
>
> Eric
>
> = [...]
>>
>> REQ 21: Does this imply that a node must = be able to deduce overload of a
>> peer or indirectly = accessible node based on local metrics only (response
>> time, send queue depth, etc)? Since "The mechanism MUST = properly function
>> in these cases", does that require that = explicit messaging is unnecessary?
>>
>>
>> = perhaps "properly function" should be stated differently. The = intent here
>> is that the mechanism not break things in this case and that = the overload is
>> handled at least as well as it would have = been were the overload control
>> signaling intact. The = language in req 17 is close to this point I think.
>> How about we barrow that language?
>>
>> REQ = 21: In cases where a network node fails, is so overloaded = that
>> it cannot = process messages, or cannot communicate due to a
>> network failure, it = may not be able to provide explicit
>> = indications of the nature of the failure or its = levels of
>> = congestion. The mechanism MUST result
>> in at least as much = useful throughput as would have resulted
>> = if the overload control signaling were = present.
>>
>>
>> This may imply the actions = you mention, as so other requirements around
>> functioning in environments with nodes that do, and do not = support the
>> mechanism, and fairness in that case. = Overload can be mitigated somewhat
>> without overload = control signaling, but that is not sufficient to handle
>> issues that are occurring on networks now. A good bit of = the front matter
>> in the draft discusses this = point.
>
>
> It seems to me that if overload signaling = is worthwhile, it must be because
> it increases useful throughput (at least in some cases).
> So = I would expect that useful throughput without overload procedures = <=3D
> useful throughput with only local overload procedures = <=3D useful throughput
> with explicit signaling. Hence I would expect something more = like this:
>
> ALT REQ 21: In cases where = a network node fails, is so overloaded that
> = it cannot process messages, or cannot communicate = due to a
> network failure, it may = not be able to provide explicit
> = indications of the nature of the failure or its levels = of
> congestion. = In this case, actions based on local metrics at the
> affected
> or = adjacent nodes may still provide some benefit.
> = The mechanism MUST result in at least as = much useful throughput
> as
> = if the affected nodes did not implement the mechanism.
> The mechanism SHOULD = result in more useful throughput than if
> none
> = of the nodes implemented the = mechanism.
>
> Does that make sense? Or have I = misunderstood completely?
>
>
> I think this shouldn't presuppose actions based on = local metrics. It is
> possible for the mechanism to do = other things such as using other paths to
> communicate = information. That said, if there truly is no path to
> communicate overload information, the overload mechanism can't = really do
> more than could be done now, in its absence. So = I'm not sure the SHOULD on
> the end would add = anything.
>

I'd be ok with simply removing the mention of local metrics and the = SHOULD. However, that is somewhat weaker than what you suggested = in the REQ 21 above. On the other hand, REQ 21 above confused me a = bit on transitional issues (the time between when the node fails and = others find out about it, especially if the adjacent nodes do not = support the mechanism and can't signal others on behalf of the failed = node).
Does this come closer to capturing the intent of REQ 21, while = satisfying the transitional issues? Or have I misunderstood the = intent?

ALT REQ 21: In cases where a network node X fails, is so = overloaded that
= it cannot process messages, or cannot communicate = due to a
=           network failure, = it may not be able to provide explicit
=           = indications of the nature of the failure or its levels of
= =             = congestion.
          = ;          In this case, = the mechanism MUST result in at least as much
=             &n= bsp;       useful throughput as if none of = the nodes implemented the = mechanism.
          =           Also, if all = relevant nodes support the mechanism, and once sufficient = nodes
           = ;         have discovered that X = has become unavailable, the mechanism MUST
=             &n= bsp;       result in at least as much = useful throughput as would have resulted if = X
           &nb= sp;        had successfully signaled = complete overload.

> [...]
>

= --Apple-Mail=_7D384B27-C522-4F13-9DEF-3BFBFFD22640-- From emcmurry@computer.org Thu Feb 21 12:42:22 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D2521F8F12 for ; Thu, 21 Feb 2013 12:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3s7lMXckb6T for ; Thu, 21 Feb 2013 12:42:21 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id C4A4121F8F10 for ; Thu, 21 Feb 2013 12:42:20 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8cyC-0000Ru-9i; Thu, 21 Feb 2013 20:42:20 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 1C58D1F557E1; Thu, 21 Feb 2013 14:42:19 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+zfFx+lsnv6h44Xl8nbBPJhvHaAvad8tU= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6cdnirXqyEC; Thu, 21 Feb 2013 14:42:19 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id F1AB41F557C9; Thu, 21 Feb 2013 14:42:18 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5CA28560-5876-41AF-A476-9BE910543490" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Eric McMurry In-Reply-To: <63660CEB-5FBF-462D-AEAC-907F07B81586@computer.org> Date: Thu, 21 Feb 2013 14:42:18 -0600 Message-Id: <3B2A3BF9-6748-49DD-8DCD-47E0E05CD6A8@computer.org> References:

<5CA501AC-1BF9-420F-96E3-938304065C6D@computer.org> <63660CEB-5FBF-462D-AEAC-907F07B81586@computer.org> To: Andrew Booth X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:42:22 -0000 --Apple-Mail=_5CA28560-5876-41AF-A476-9BE910543490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ben caught me in a thinko on this one. Here is the corrected proposal: REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of congestion. The mechanism MUST result in at least as much useful throughput as would have resulted if the overload control mechanism was not in place. On Feb 21, 2013, at 14:32 , Eric McMurry wrote: > okay. Here's what I have in my working copy of the 04 reqs: >=20 > REQ 21: In cases where a network node fails, is so overloaded that > it cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > congestion. The mechanism MUST result in at least as much > useful throughput as would have resulted if the overload > control signaling were present. >=20 > This wasn't too far from the original, but I think the wording is more = clear. I think this was from the first or second round of our = conversation. >=20 > thanks, >=20 > Eric >=20 >=20 >=20 > On Feb 21, 2013, at 14:15 , Andrew Booth = wrote: >=20 >> When I re-read the thread, I was worried that I'd neutered REQ 21 = away from what you originally intended. >> Sounds like I'm just over-complicating things. Let's take a step = back. >>=20 >> What is your current favorite candidate for REQ 21? >>=20 >> Andrew >>=20 >> On Thu, Feb 21, 2013 at 2:35 PM, Eric McMurry = wrote: >> Hi Andrew, >>=20 >> I'm a bit lost on what you are wanting to add here. The gist of this = requirement is that the mechanism shouldn't make things worse in this = situation, and no more than that. >> =20 >> I don't think we can strengthen that to the point that the mechanism = will work the same in cases where signaling is not possible as in cases = where it is, and requiring that it find ways to route overload signaling = information around the issues is probably saying too much about the = implementation. >>=20 >> I'm also not understanding your comment on transitional issues and = how it relates here. >>=20 >> Sorry, I'm a bit slow today. you'll have to bear with me :-) >>=20 >> Thanks, >>=20 >> Eric >>=20 >>=20 >> On Feb 21, 2013, at 13:14 , Andrew Booth = wrote: >>=20 >>> Hi Eric, >>>=20 >>> Comments inline. >>>=20 >>> Thanks, >>> Andrew >>>=20 >>> On Wed, Feb 20, 2013 at 4:45 PM, Eric McMurry = wrote: >>> > Hi Andrew, >>> > >>> > comments inline. >>> > >>> > Thanks, >>> > >>> > Eric >>> > >>> > [...] >>> >> >>> >> REQ 21: Does this imply that a node must be able to deduce = overload of a >>> >> peer or indirectly accessible node based on local metrics only = (response >>> >> time, send queue depth, etc)? Since "The mechanism MUST properly = function >>> >> in these cases", does that require that explicit messaging is = unnecessary? >>> >> >>> >> >>> >> perhaps "properly function" should be stated differently. The = intent here >>> >> is that the mechanism not break things in this case and that the = overload is >>> >> handled at least as well as it would have been were the overload = control >>> >> signaling intact. The language in req 17 is close to this point = I think.=20 >>> >> How about we barrow that language? >>> >> >>> >> REQ 21: In cases where a network node fails, is so overloaded = that >>> >> it cannot process messages, or cannot communicate due = to a >>> >> network failure, it may not be able to provide = explicit >>> >> indications of the nature of the failure or its = levels of >>> >> congestion. The mechanism MUST result >>> >> in at least as much useful throughput as would have = resulted >>> >> if the overload control signaling were present. >>> >> >>> >> >>> >> This may imply the actions you mention, as so other requirements = around >>> >> functioning in environments with nodes that do, and do not = support the >>> >> mechanism, and fairness in that case. Overload can be mitigated = somewhat >>> >> without overload control signaling, but that is not sufficient to = handle >>> >> issues that are occurring on networks now. A good bit of the = front matter >>> >> in the draft discusses this point. >>> > >>> > >>> > It seems to me that if overload signaling is worthwhile, it must = be because >>> > it increases useful throughput (at least in some cases). >>> > So I would expect that useful throughput without overload = procedures <=3D >>> > useful throughput with only local overload procedures <=3D useful = throughput >>> > with explicit signaling. Hence I would expect something more like = this: >>> > >>> > ALT REQ 21: In cases where a network node fails, is so = overloaded that >>> > it cannot process messages, or cannot communicate due = to a >>> > network failure, it may not be able to provide = explicit >>> > indications of the nature of the failure or its levels = of >>> > congestion. In this case, actions based on local = metrics at the >>> > affected >>> > or adjacent nodes may still provide some benefit. >>> > The mechanism MUST result in at least as much useful = throughput >>> > as >>> > if the affected nodes did not implement the mechanism. >>> > The mechanism SHOULD result in more useful throughput = than if >>> > none >>> > of the nodes implemented the mechanism. >>> > >>> > Does that make sense? Or have I misunderstood completely? >>> > >>> > >>> > I think this shouldn't presuppose actions based on local metrics. = It is >>> > possible for the mechanism to do other things such as using other = paths to >>> > communicate information. That said, if there truly is no path to >>> > communicate overload information, the overload mechanism can't = really do >>> > more than could be done now, in its absence. So I'm not sure the = SHOULD on >>> > the end would add anything. >>> > >>>=20 >>> I'd be ok with simply removing the mention of local metrics and the = SHOULD. However, that is somewhat weaker than what you suggested in the = REQ 21 above. On the other hand, REQ 21 above confused me a bit on = transitional issues (the time between when the node fails and others = find out about it, especially if the adjacent nodes do not support the = mechanism and can't signal others on behalf of the failed node). >>> Does this come closer to capturing the intent of REQ 21, while = satisfying the transitional issues? Or have I misunderstood the intent? >>>=20 >>> ALT REQ 21: In cases where a network node X fails, is so overloaded = that >>> it cannot process messages, or cannot = communicate due to a >>> network failure, it may not be able to provide = explicit >>> indications of the nature of the failure or its = levels of >>> congestion. >>> In this case, the mechanism MUST result in at = least as much >>> useful throughput as if none of the nodes = implemented the mechanism. >>> Also, if all relevant nodes support the = mechanism, and once sufficient nodes >>> have discovered that X has become unavailable, = the mechanism MUST >>> result in at least as much useful throughput as = would have resulted if X >>> had successfully signaled complete overload. >>>=20 >>>=20 >>> > [...] >>> > >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_5CA28560-5876-41AF-A476-9BE910543490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ben = caught me in a thinko on this one. Here is the corrected = proposal:

emcmurry@computer.org> = wrote:

okay. = Here's what I have in my working copy of the 04 = reqs:

REQ 21: In cases where a network = node fails, is so overloaded that
= it cannot process messages, or cannot communicate due to = a
network failure, = it may not be able to provide explicit
= indications of the nature of the failure or its = levels of
= congestion. The mechanism MUST result in at least as = much
useful = throughput as would have resulted if the overload
= control signaling were = present.

This wasn't too far from the = original, but I think the wording is more clear. I think this was = from the first or second round of our = conversation.

thanks,

Er= ic

On Feb 21, = 2013, at 14:15 , Andrew Booth <lists.abooth@gmail.com> = wrote:

When I re-read the thread, I was worried that I'd = neutered REQ 21 away from what you originally intended.
Sounds like = I'm just over-complicating things. Let's take a step = back.

What is your current favorite candidate for REQ 21?

Andrew

On Thu, Feb 21, 2013 at = 2:35 PM, Eric McMurry <emcmurry@computer.org> = wrote:

Hi Andrew,

I'm a = bit lost on what you are wanting to add here. The gist of this = requirement is that the mechanism shouldn't make things worse in this = situation, and no more than that.

I don't think we can strengthen = that to the point that the mechanism will work the same in cases where = signaling is not possible as in cases where it is, and requiring that it = find ways to route overload signaling information around the issues is = probably saying too much about the implementation.

I'm also not understanding your comment on = transitional issues and how it relates = here.

Sorry, I'm a bit slow today. you'll = have to bear with me :-)

Thanks,

Eric

On Feb 21, 2013, at 13:14 = , Andrew Booth <lists.abooth@gmail.com> wrote:

Hi Eric,

Comments = inline.

Thanks,
Andrew

On Wed, Feb 20, 2013 at 4:45 PM, = Eric McMurry <emcmurry@computer.org> wrote:
> Hi Andrew,
>
> comments inline.
>
> Thanks,
>
> Eric
>
> = [...]
>>
>> REQ 21: Does this imply that a node must = be able to deduce overload of a
>> peer or indirectly = accessible node based on local metrics only (response
>> time, send queue depth, etc)? Since "The mechanism MUST = properly function
>> in these cases", does that require that = explicit messaging is unnecessary?
>>
>>
>> = perhaps "properly function" should be stated differently. The = intent here
>> is that the mechanism not break things in this case and that = the overload is
>> handled at least as well as it would have = been were the overload control
>> signaling intact. The = language in req 17 is close to this point I think.
>> How about we barrow that language?
>>
>> REQ = 21: In cases where a network node fails, is so overloaded = that
>> it cannot = process messages, or cannot communicate due to a
>> network failure, it = may not be able to provide explicit
>> = indications of the nature of the failure or its = levels of
>> = congestion. The mechanism MUST result
>> in at least as much = useful throughput as would have resulted
>> = if the overload control signaling were = present.
>>
>>
>> This may imply the actions = you mention, as so other requirements around
>> functioning in environments with nodes that do, and do not = support the
>> mechanism, and fairness in that case. = Overload can be mitigated somewhat
>> without overload = control signaling, but that is not sufficient to handle
>> issues that are occurring on networks now. A good bit of = the front matter
>> in the draft discusses this = point.
>
>
> It seems to me that if overload signaling = is worthwhile, it must be because
> it increases useful throughput (at least in some cases).
> So = I would expect that useful throughput without overload procedures = <=3D
> useful throughput with only local overload procedures = <=3D useful throughput
> with explicit signaling. Hence I would expect something more = like this:
>
> ALT REQ 21: In cases where = a network node fails, is so overloaded that
> = it cannot process messages, or cannot communicate = due to a
> network failure, it may = not be able to provide explicit
> = indications of the nature of the failure or its levels = of
> congestion. = In this case, actions based on local metrics at the
> affected
> or = adjacent nodes may still provide some benefit.
> = The mechanism MUST result in at least as = much useful throughput
> as
> = if the affected nodes did not implement the mechanism.
> The mechanism SHOULD = result in more useful throughput than if
> none
> = of the nodes implemented the = mechanism.
>
> Does that make sense? Or have I = misunderstood completely?
>
>
> I think this shouldn't presuppose actions based on = local metrics. It is
> possible for the mechanism to do = other things such as using other paths to
> communicate = information. That said, if there truly is no path to
> communicate overload information, the overload mechanism can't = really do
> more than could be done now, in its absence. So = I'm not sure the SHOULD on
> the end would add = anything.
>

I'd be ok with simply removing the mention of local metrics and the = SHOULD. However, that is somewhat weaker than what you suggested = in the REQ 21 above. On the other hand, REQ 21 above confused me a = bit on transitional issues (the time between when the node fails and = others find out about it, especially if the adjacent nodes do not = support the mechanism and can't signal others on behalf of the failed = node).
Does this come closer to capturing the intent of REQ 21, while = satisfying the transitional issues? Or have I misunderstood the = intent?

ALT REQ 21: In cases where a network node X fails, is so = overloaded that
= it cannot process messages, or cannot communicate = due to a
=           network failure, = it may not be able to provide explicit
=           = indications of the nature of the failure or its levels of
= =             = congestion.
          = ;          In this case, = the mechanism MUST result in at least as much
=             &n= bsp;       useful throughput as if none of = the nodes implemented the = mechanism.
          =           Also, if all = relevant nodes support the mechanism, and once sufficient = nodes
           = ;         have discovered that X = has become unavailable, the mechanism MUST
=             &n= bsp;       result in at least as much = useful throughput as would have resulted if = X
           &nb= sp;        had successfully signaled = complete overload.

> [...]
>

=

_______________________________________= ________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dime

= --Apple-Mail=_5CA28560-5876-41AF-A476-9BE910543490-- From emcmurry@computer.org Thu Feb 21 12:57:48 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68321F8F5E for ; Thu, 21 Feb 2013 12:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJVYRoDITdKG for ; Thu, 21 Feb 2013 12:57:47 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2D21F8F51 for ; Thu, 21 Feb 2013 12:57:47 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1U8dD9-0009ai-29 for dime@ietf.org; Thu, 21 Feb 2013 20:57:47 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id F1FB81F5637A for ; Thu, 21 Feb 2013 14:57:45 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18GGF5tFcnIf/TtkqY8Iy0juSifaqMT3U0= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnSsQExOdSGp for ; Thu, 21 Feb 2013 14:57:45 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 930AB1F56369 for ; Thu, 21 Feb 2013 14:57:45 -0600 (CST) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_D239363C-0A95-41F6-A0E9-4BE78E821422" Message-Id: <1DBA9DAE-0B0E-4A26-B089-F58674368C2B@computer.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) Date: Thu, 21 Feb 2013 14:57:43 -0600 References: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> To: "dime@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1499) Subject: Re: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:57:48 -0000 --Apple-Mail=_D239363C-0A95-41F6-A0E9-4BE78E821422 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 20, 2013, at 13:52 , Andrew Booth wrote: There has been some additional comment on this with concern that = specifying offered load and overall capacity here may be to restricting = on the mechanism design. How does this wording work for everyone: The overload control mechanism and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the = mechanism MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload = condition. Note that this also requires that the mechanism MUST allow nodes to shed load without introducing oscillations during or after = an overload condition. thanks! Eric > Works for me. >=20 > Thanks, > Andrew >=20 > On Wed, Feb 20, 2013 at 2:38 PM, Eric McMurry = wrote: > Req 7 reads: The overload control mechanism and any associated = default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall = capacity > of the network to below the overall capacity, the = throughput > MUST stabilize and become equal to the offered load. Note > that this also requires that the mechanism MUST allow = nodes > to shed load without introducing oscillations. >=20 >=20 > It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound: >=20 >=20 > The overload control mechanism and any associated default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall = capacity > of the network to below the overall capacity, the = mechanism > MUST enable throughput to stabilize and become > equal to the offered load. Note > that this also requires that the mechanism MUST allow = nodes > to shed load without introducing oscillations. >=20 >=20 > Thanks, >=20 > Eric >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 --Apple-Mail=_D239363C-0A95-41F6-A0E9-4BE78E821422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 lists.abooth@gmail.com> = wrote:

There has been some additional comment on this with = concern that specifying offered load and overall capacity here may be to = restricting on the mechanism design.

How does = this wording work for everyone:

The overload = control mechanism and any associated default
MUST = enable capacity to stabilize and become
that = this also requires that the mechanism MUST allow nodes

Works for = me.

Thanks,
Andrew

On Wed, = Feb 20, 2013 at 2:38 PM, Eric McMurry <emcmurry@computer.org> wrote:

Req 7 reads: The = overload control mechanism and any associated default
algorithm(s) MUST ensure that = the system remains stable.
When the offered load drops = from above the overall capacity
of the network to below the = overall capacity, the throughput
MUST stabilize and become = equal to the offered load. Note
that this also requires that = the mechanism MUST allow nodes
to shed load without = introducing oscillations.

It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound:

The overload control mechanism and any associated = default
algorithm(s) MUST ensure that = the system remains stable.
When the offered load drops = from above the overall capacity
of the network to below the = overall capacity, the mechanism
MUST enable throughput to = stabilize and become
equal to the offered load. = Note
that this also requires that = the mechanism MUST allow nodes
to shed load without = introducing oscillations.

Thanks,

Eric

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

= --Apple-Mail=_D239363C-0A95-41F6-A0E9-4BE78E821422-- From jouni.nospam@gmail.com Thu Feb 21 14:07:09 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F8F21E8039 for ; Thu, 21 Feb 2013 14:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOgVHLIIu6zF for ; Thu, 21 Feb 2013 14:07:09 -0800 (PST) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id CD89321F8E79 for ; Thu, 21 Feb 2013 14:07:08 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id c13so6899eaa.16 for ; Thu, 21 Feb 2013 14:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=os2fw5oJXIcBttMtl/qS0ajMYw0D6ycxcEWOS6cGqAs=; b=YheWxVaBPHUhqjAZEtIVFzgBo8UeKX2IQe3Ezj6CQWk1qp+NXc7EpUWO6yFs2sYZiK 3Y/tR4E7r4+TIkKUlYPGqPpfqsLSO2UPtUGtSLpBdhwcTn9sIHNZqbuX0nPFNjuN1+a5 kLTPGJku9LSeK1mlICQo+Cg/IV0e6TIdMdRzMQiLZJisiEEwHwKOASlHLTxd+LAZaPFF gAypB6Lzy9GEm4x66FWi7IB2FHU3GdTOLQONIMi2zWr/aqvYhI/ex5AEqZ2xf3BeHdKt NRE2KoDhYucr+uzdVKQvezhKF8175+jH1rL1U9m1X0emkE4PHTmEGIGhkYHt8iimyge6 WJHA== X-Received: by 10.14.218.71 with SMTP id j47mr84713140eep.28.1361484427946; Thu, 21 Feb 2013 14:07:07 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:7c10:ba68:fe01:899d? ([2001:1bc8:101:f101:7c10:ba68:fe01:899d]) by mx.google.com with ESMTPS id f47sm74198eep.13.2013.02.21.14.07.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 14:07:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Jouni Korhonen In-Reply-To: <461BC1A5-C193-44D4-9AF7-C0D256AD59F9@nostrum.com> Date: Fri, 22 Feb 2013 00:07:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59787EF2-ECD1-4EC9-B97B-200384FE88F5@gmail.com> References: <461BC1A5-C193-44D4-9AF7-C0D256AD59F9@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control req 16 is needed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:07:09 -0000 The new wording works for me. - Jouni On Feb 20, 2013, at 9:52 PM, Ben Campbell wrote: >=20 > On Feb 20, 2013, at 1:38 PM, Eric McMurry = wrote: >=20 >> It has been pointed out that Req 16 has some ambiguity to it, around = the meaning of "without malfunction". Looking at it a bit closer, along = with the next couple of requirements, it does not seem to be adding = anything. I think Reqs 17 and 18 cover what this was trying to = communicate, and it would make things more clear to just remove it. = Does this make sense? >=20 > In retrospect, I'm not sure I agree with this one. 16 is the = requirement that explicitly requires support for mixed environment. 17 = and 18 further constrain that. If we remove 16, then 17 and 18 will = still _imply_ the requirement to support mixed environments--but it's = better to be explicit. >=20 > How about the following alternative text for 16: >=20 > "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." >=20 >>=20 >> Thanks, >>=20 >> Eric >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Feb 21 14:08:27 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5660A21F8621 for ; Thu, 21 Feb 2013 14:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNaASq8t0qEh for ; Thu, 21 Feb 2013 14:08:26 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4FF21E8030 for ; Thu, 21 Feb 2013 14:08:19 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so7146eei.35 for ; Thu, 21 Feb 2013 14:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=RPPeSJZEPoA9wemm0Yv/y52nYM+ch7n1ExDB7OwLcXw=; b=MirRTa1f6gpJzCNTak7w42O+MgWXhctc2bfTVr4j48HkRORT68U2eOXSkisLXUGmBv iaHJaserOjkdWFrKVRLLllsFp2nopyNHfIOqvi6SL8R8fWXtLSXsH1xc2W3QhRABpTp+ mWUdldTXucRaji1Jdxq7DysXS37whVfV+16M3QlcXMJvt9WXS/fE/QmhyyDs7Hw2rICj Xwzyn2UIUvno274mhkinrs0MS5qZv103C2mznA/dxYWxxaDqHqjR5QdWBWpaXHQqM7FE PRaFzMFQ6Xj07lARAHgJFxwXYH/yav5y48RcVRUOxWMu3+FkRdmKkU4P9oOHE2lM+Rzm 66BA== X-Received: by 10.14.173.196 with SMTP id v44mr84759581eel.29.1361484498274; Thu, 21 Feb 2013 14:08:18 -0800 (PST) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id 3sm104575eej.6.2013.02.21.14.08.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 14:08:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Jouni Korhonen In-Reply-To: Date: Fri, 22 Feb 2013 00:08:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC4C7EA-98AF-4715-B180-3092EBC17D4A@gmail.com> References: To: Eric McMurry X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 10 on end of overload condition X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:08:27 -0000 New text looks OK. - Jouni On Feb 20, 2013, at 9:38 PM, Eric McMurry wrote: > Req 10 reads: Consumers of overload state indications MUST be able to > determine when the overload condition improves or ends. >=20 > It has been pointed out that the term "overload state indications" may = imply aspects of implementation. In the rest of the document the more = generic "overload information" is generally used. I think it would make = sense to use that here as well. So Req 10 would read: >=20 > Consumers of overload information MUST be able to > determine when the overload condition improves or ends. >=20 > Thanks, >=20 > Eric >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Feb 21 14:14:41 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDDA21E8043 for ; Thu, 21 Feb 2013 14:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsF2uMle0XWK for ; Thu, 21 Feb 2013 14:14:40 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBFD21E8030 for ; Thu, 21 Feb 2013 14:14:40 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id c13so11667eek.0 for ; Thu, 21 Feb 2013 14:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=BcnTQaVyORw8wHPEmoGSz3F9R+dBTFl+ezxzey5nrJ0=; b=b1ct9LvtUadcm3Z4bAmzAbWpGLnSFRujvzfIri12Wp9nDBffGaRa979iSFeVd/36UK pUCriv7avC2PpVJ5C9e7zzkyRgJAwzJZyQ9XbomdlOgMmOJkY6P58aTRxGpAW8myvDg/ ABs8zqiv40PyVQcswk6aJf3vebSU8bG7BK5ssxRuOvcpkBHvmPu8IF4ekPz6zmSUq66i xMPhFzMsaV36pQYSU0z+i/EAp9N43Mzjja66ECttrwY+OB8etNX6A2IHN0ymQ5gyl5f7 DV9w92FlnPWDogFXfymsaiU1mU31+L6f0ipn7Bf0+xP+KXUzlS3L+CKHfWvBH4tsA020 DMgA== X-Received: by 10.14.211.65 with SMTP id v41mr84780223eeo.33.1361484879758; Thu, 21 Feb 2013 14:14:39 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:7c10:ba68:fe01:899d? ([2001:1bc8:101:f101:7c10:ba68:fe01:899d]) by mx.google.com with ESMTPS id s3sm138573eem.4.2013.02.21.14.14.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 14:14:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Jouni Korhonen In-Reply-To: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> Date: Fri, 22 Feb 2013 00:14:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D2C8749-2777-49C2-B41E-D82C2B2BE8EC@gmail.com> References: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:14:41 -0000 I would still argue that "..the mechanism MUST enable throughput.." could use some rewording. The load in the network might not be about 'throughput' as in bps but for example about transactions. - Jouni On Feb 20, 2013, at 9:38 PM, Eric McMurry wrote: > Req 7 reads: The overload control mechanism and any associated = default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall capacity > of the network to below the overall capacity, the = throughput > MUST stabilize and become equal to the offered load. Note > that this also requires that the mechanism MUST allow nodes > to shed load without introducing oscillations. >=20 >=20 > It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound: >=20 >=20 > The overload control mechanism and any associated default > algorithm(s) MUST ensure that the system remains stable. > When the offered load drops from above the overall capacity > of the network to below the overall capacity, the mechanism > MUST enable throughput to stabilize and become > equal to the offered load. Note > that this also requires that the mechanism MUST allow nodes > to shed load without introducing oscillations. >=20 >=20 > Thanks, >=20 > Eric >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lists.abooth@gmail.com Thu Feb 21 17:23:22 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FD321F8430 for ; Thu, 21 Feb 2013 17:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6H0a++-T9Va for ; Thu, 21 Feb 2013 17:23:21 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6191221F8713 for ; Thu, 21 Feb 2013 17:23:19 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id 1so86010qee.40 for ; Thu, 21 Feb 2013 17:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4DKV950cXpM7l9TOtC36qQ4skaIJpiw9NsLZnnlCln0=; b=ns2Ty2vQu2lPCJ30R8JgBttXhFoU0P6brsMj1V40lg/JpGxaYJRYG7Z9tbeprQIXw/ fKPq2Rz/YvRpv0GTNCCj2YVXxANa13G2gvqs+HeNpvKQM8pQgo2DvIEqSj1l2JQR9rtD gWNE/+PFlTUbtscLIN4Zu4em/1M39QZeiTaiYCoJxNCchbAps0CqX8bfrB4q/MaclFAE ohvf+gTc50VxcjVuGYChqItPv8Bqi0aA7KGHzdDvLnU+KA7Ip2S6hicv2NkNswqousBg mAcw8r6RupUbTAYh78cXwEElAY4wSElJbJJ+uaKlwe/OSkQuEbbVG7y6QDNxpOtbuH6U q4dA== MIME-Version: 1.0 X-Received: by 10.49.2.7 with SMTP id 7mr49700qeq.45.1361496197785; Thu, 21 Feb 2013 17:23:17 -0800 (PST) Received: by 10.49.63.163 with HTTP; Thu, 21 Feb 2013 17:23:17 -0800 (PST) In-Reply-To: <3B2A3BF9-6748-49DD-8DCD-47E0E05CD6A8@computer.org> References:

<5CA501AC-1BF9-420F-96E3-938304065C6D@computer.org> <63660CEB-5FBF-462D-AEAC-907F07B81586@computer.org> <3B2A3BF9-6748-49DD-8DCD-47E0E05CD6A8@computer.org> Date: Thu, 21 Feb 2013 20:23:17 -0500 Message-ID: From: Andrew Booth To: Eric McMurry Content-Type: multipart/alternative; boundary=047d7b6785fc3b703e04d6460959 Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:23:23 -0000 --047d7b6785fc3b703e04d6460959 Content-Type: text/plain; charset=ISO-8859-1 That works for me. Thanks! Andrew On Thu, Feb 21, 2013 at 3:42 PM, Eric McMurry wrote: > Ben caught me in a thinko on this one. Here is the corrected proposal: > > REQ 21: In cases where a network node fails, is so overloaded that > it cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > congestion. The mechanism MUST result in at least as much > useful throughput as would have resulted if the overload > control mechanism was not in place. > > On Feb 21, 2013, at 14:32 , Eric McMurry wrote: > > okay. Here's what I have in my working copy of the 04 reqs: > > REQ 21: In cases where a network node fails, is so overloaded that > it cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > congestion. The mechanism MUST result in at least as much > useful throughput as would have resulted if the overload > control signaling were present. > > This wasn't too far from the original, but I think the wording is more > clear. I think this was from the first or second round of our conversation. > > thanks, > > Eric > > > > On Feb 21, 2013, at 14:15 , Andrew Booth wrote: > > When I re-read the thread, I was worried that I'd neutered REQ 21 away > from what you originally intended. > Sounds like I'm just over-complicating things. Let's take a step back. > > What is your current favorite candidate for REQ 21? > > Andrew > > On Thu, Feb 21, 2013 at 2:35 PM, Eric McMurry wrote: > >> Hi Andrew, >> >> I'm a bit lost on what you are wanting to add here. The gist of this >> requirement is that the mechanism shouldn't make things worse in this >> situation, and no more than that. >> > >> > I don't think we can strengthen that to the point that the mechanism will >> work the same in cases where signaling is not possible as in cases where it >> is, and requiring that it find ways to route overload signaling information >> around the issues is probably saying too much about the implementation. >> >> I'm also not understanding your comment on transitional issues and how it >> relates here. >> >> Sorry, I'm a bit slow today. you'll have to bear with me :-) >> >> Thanks, >> >> Eric >> >> >> On Feb 21, 2013, at 13:14 , Andrew Booth wrote: >> >> Hi Eric, >> >> Comments inline. >> >> Thanks, >> Andrew >> >> On Wed, Feb 20, 2013 at 4:45 PM, Eric McMurry >> wrote: >> > Hi Andrew, >> > >> > comments inline. >> > >> > Thanks, >> > >> > Eric >> > >> > [...] >> >> >> >> REQ 21: Does this imply that a node must be able to deduce overload of >> a >> >> peer or indirectly accessible node based on local metrics only >> (response >> >> time, send queue depth, etc)? Since "The mechanism MUST properly >> function >> >> in these cases", does that require that explicit messaging is >> unnecessary? >> >> >> >> >> >> perhaps "properly function" should be stated differently. The intent >> here >> >> is that the mechanism not break things in this case and that the >> overload is >> >> handled at least as well as it would have been were the overload >> control >> >> signaling intact. The language in req 17 is close to this point I >> think. >> >> How about we barrow that language? >> >> >> >> REQ 21: In cases where a network node fails, is so overloaded that >> >> it cannot process messages, or cannot communicate due to a >> >> network failure, it may not be able to provide explicit >> >> indications of the nature of the failure or its levels of >> >> congestion. The mechanism MUST result >> >> in at least as much useful throughput as would have >> resulted >> >> if the overload control signaling were present. >> >> >> >> >> >> This may imply the actions you mention, as so other requirements around >> >> functioning in environments with nodes that do, and do not support the >> >> mechanism, and fairness in that case. Overload can be mitigated >> somewhat >> >> without overload control signaling, but that is not sufficient to >> handle >> >> issues that are occurring on networks now. A good bit of the front >> matter >> >> in the draft discusses this point. >> > >> > >> > It seems to me that if overload signaling is worthwhile, it must be >> because >> > it increases useful throughput (at least in some cases). >> > So I would expect that useful throughput without overload procedures <= >> > useful throughput with only local overload procedures <= useful >> throughput >> > with explicit signaling. Hence I would expect something more like this: >> > >> > ALT REQ 21: In cases where a network node fails, is so overloaded >> that >> > it cannot process messages, or cannot communicate due to a >> > network failure, it may not be able to provide explicit >> > indications of the nature of the failure or its levels of >> > congestion. In this case, actions based on local metrics >> at the >> > affected >> > or adjacent nodes may still provide some benefit. >> > The mechanism MUST result in at least as much useful >> throughput >> > as >> > if the affected nodes did not implement the mechanism. >> > The mechanism SHOULD result in more useful throughput than >> if >> > none >> > of the nodes implemented the mechanism. >> > >> > Does that make sense? Or have I misunderstood completely? >> > >> > >> > I think this shouldn't presuppose actions based on local metrics. It is >> > possible for the mechanism to do other things such as using other paths >> to >> > communicate information. That said, if there truly is no path to >> > communicate overload information, the overload mechanism can't really do >> > more than could be done now, in its absence. So I'm not sure the >> SHOULD on >> > the end would add anything. >> > >> >> I'd be ok with simply removing the mention of local metrics and the >> SHOULD. However, that is somewhat weaker than what you suggested in the >> REQ 21 above. On the other hand, REQ 21 above confused me a bit on >> transitional issues (the time between when the node fails and others find >> out about it, especially if the adjacent nodes do not support the mechanism >> and can't signal others on behalf of the failed node). >> Does this come closer to capturing the intent of REQ 21, while satisfying >> the transitional issues? Or have I misunderstood the intent? >> >> ALT REQ 21: In cases where a network node X fails, is so overloaded that >> it cannot process messages, or cannot communicate due >> to a >> network failure, it may not be able to provide >> explicit >> indications of the nature of the failure or its >> levels of >> congestion. >> In this case, the mechanism MUST result in at least >> as much >> useful throughput as if none of the nodes implemented >> the mechanism. >> Also, if all relevant nodes support the mechanism, >> and once sufficient nodes >> have discovered that X has become unavailable, the >> mechanism MUST >> result in at least as much useful throughput as would >> have resulted if X >> had successfully signaled complete overload. >> >> >> > [...] >> > >> >> >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > --047d7b6785fc3b703e04d6460959 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That works for me.

Thanks!
Andrew

On Thu, Feb 21, 2013 at 3:42 PM, Eric McMurry <emcmurry@computer.or= g> wrote:

Ben caug= ht me in a thinko on this one. =A0Here is the corrected proposal:

<= /div>
REQ 21: =A0= In cases where a network node fails, is so overloaded that
=A0 = =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot communicate due t= o a
=A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able t= o provide explicit

=A0 =A0 =A0 =A0 =A0 =A0 indications of the nature of the failure or it= s levels of
=A0 =A0 =A0 =A0 =A0 =A0 congestion. =A0The mechanism = MUST result in at least as much
=A0 =A0 =A0 =A0 =A0 =A0 useful th= roughput as would have resulted if the overload

=A0 =A0 =A0 =A0 =A0 =A0 control mechanism was not in place.

On Feb 21, 2013, at = 14:32 , Eric McMurry <emcmurry@computer.org> wrote:

okay. =A0Here's what I have in my working cop= y of the 04 reqs:

REQ 21: =A0In cases where a netwo= rk node fails, is so overloaded that

=A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot communic= ate due to a
=A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not = be able to provide explicit
=A0 =A0 =A0 =A0 =A0 =A0 indications o= f the nature of the failure or its levels of

=A0 =A0 =A0 =A0 =A0 =A0 congestion. =A0The mechanism MUST result in at= least as much
=A0 =A0 =A0 =A0 =A0 =A0 useful throughput as would= have resulted if the overload
=A0 =A0 =A0 =A0 =A0 =A0 control si= gnaling were present.

This wasn't too far from the original, but I think the w= ording is more clear. =A0I think this was from the first or second round of= our conversation.

thanks,

Eric

On Feb 21, 2013,= at 14:15 , Andrew Booth <lists.abooth@gmail.com> wrote:

When I re-read the thread, I was worried that I'd neutered REQ 21 away= from what you originally intended.
Sounds like I'm just over-compli= cating things.=A0 Let's take a step back.

What is your current f= avorite candidate for REQ 21?

Andrew

On Thu, Feb 21, 2013 at 2:35 P= M, Eric McMurry <emcmurry@computer.org> wrote:

Hi Andrew,

I'm a= bit lost on what you are wanting to add here. =A0The gist of this requirem= ent is that the mechanism shouldn't make things worse in this situation= , and no more than that.

=
=A0

I don't think we can strengthe= n that to the point that the mechanism will work the same in cases where si= gnaling is not possible as in cases where it is, and requiring that it find= ways to route overload signaling information around the issues is probably= saying too much about the implementation.

I'm also not understanding your comment on transiti= onal issues and how it relates here.

Sorry, I'= m a bit slow today. =A0you'll have to bear with me :-)

Thanks,

Eric

On Feb 21, 2013, at 13:14 , Andrew Booth <lists.abooth@gmail.com= > wrote:

Hi Eric,

Comments inline.

Thank= s,
Andrew

On Wed, Feb 20, 2013 at 4:45 PM, Eric McMurry <emcmurry@computer.org= > wrote:
> Hi Andrew,
>
> comments inline.
>
> Thanks,
>
> Eric
>
> [...]
>>=
>> REQ 21: Does this imply that a node must be able to deduce ove= rload of a
>> peer or indirectly accessible node based on local me= trics only (response
>> time, send queue depth, etc)? =A0Since "The mechanism MUST pr= operly function
>> in these cases", does that require that ex= plicit messaging is unnecessary?
>>
>>
>> perhap= s "properly function" should be stated differently. =A0The intent= here
>> is that the mechanism not break things in this case and that the o= verload is
>> handled at least as well as it would have been were = the overload control
>> signaling intact. =A0The language in req 1= 7 is close to this point I think.
>> How about we barrow that language?
>>
>> REQ 21:= =A0In cases where a network node fails, is so overloaded that
>> = =A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot communicate d= ue to a
>> =A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able to pro= vide explicit
>> =A0 =A0 =A0 =A0 =A0 =A0 indications of the nature= of the failure or its levels of
>> =A0 =A0 =A0 =A0 =A0 =A0 conges= tion. =A0The mechanism MUST result
>> =A0 =A0 =A0 =A0 =A0 =A0 in at least as much useful throughput as w= ould have resulted
>> =A0 =A0 =A0 =A0 =A0 =A0 if the overload cont= rol signaling were present.
>>
>>
>> This may im= ply the actions you mention, as so other requirements around
>> functioning in environments with nodes that do, and do not support= the
>> mechanism, and fairness in that case. =A0Overload can be m= itigated somewhat
>> without overload control signaling, but that = is not sufficient to handle
>> issues that are occurring on networks now. =A0A good bit of the fr= ont matter
>> in the draft discusses this point.
>
>> It seems to me that if overload signaling is worthwhile, it must be = because
> it increases useful throughput (at least in some cases).
> So I = would expect that useful throughput without overload procedures <=3D
= > useful throughput with only local overload procedures <=3D useful t= hroughput
> with explicit signaling. =A0Hence I would expect something more like t= his:
>
> =A0 =A0ALT REQ 21: =A0In cases where a network node fa= ils, is so overloaded that
> =A0 =A0 =A0 =A0 =A0 =A0 it cannot proces= s messages, or cannot communicate due to a
> =A0 =A0 =A0 =A0 =A0 =A0 network failure, it may not be able to provide= explicit
> =A0 =A0 =A0 =A0 =A0 =A0 indications of the nature of the = failure or its levels of
> =A0 =A0 =A0 =A0 =A0 =A0 congestion. =A0In = this case, actions based on local metrics at the
> affected
> =A0 =A0 =A0 =A0 =A0 =A0 or adjacent nodes may still p= rovide some benefit.
> =A0 =A0 =A0 =A0 =A0 =A0 The mechanism MUST res= ult in at least as much useful throughput
> as
> =A0 =A0 =A0 = =A0 =A0 =A0 if the affected nodes did not implement the mechanism.
> =A0 =A0 =A0 =A0 =A0 =A0 The mechanism SHOULD result in more useful thr= oughput than if
> none
> =A0 =A0 =A0 =A0 =A0 =A0 of the nodes i= mplemented the mechanism.
>
> Does that make sense? =A0Or have = I misunderstood completely?
>
>
> I think this shouldn't presuppose actions based on= local metrics. =A0It is
> possible for the mechanism to do other thi= ngs such as using other paths to
> communicate information. =A0That s= aid, if there truly is no path to
> communicate overload information, the overload mechanism can't rea= lly do
> more than could be done now, in its absence. =A0So I'm n= ot sure the SHOULD on
> the end would add anything.
>

I'd be ok with simply removing the mention of local metrics and the SHO= ULD.=A0 However, that is somewhat weaker than what you suggested in the REQ= 21 above.=A0 On the other hand, REQ 21 above confused me a bit on transiti= onal issues (the time between when the node fails and others find out about= it, especially if the adjacent nodes do not support the mechanism and can&= #39;t signal others on behalf of the failed node).
Does this come closer to capturing the intent of REQ 21, while satisfying t= he transitional issues?=A0 Or have I misunderstood the intent?

ALT R= EQ 21: In cases where a network node X fails, is so overloaded that
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it cannot process messages, or cannot c= ommunicate due to a
=A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 network failure, it may not= be able to provide explicit
=A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0= =A0=A0 indications of the nature of the failure or its levels of
=A0 =A0= =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 congestion.
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In this case, the mechanism MUST= result in at least as much
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 useful throughput= as if none of the nodes implemented the mechanism.
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Also, if all relevant nodes support= the mechanism, and once sufficient nodes
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 have discovered that X has become unavailable, = the mechanism MUST
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 result in at leas= t as much useful throughput as would have resulted if X
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 had successfully signaled comple= te overload.

> [...]
>

____________________________= ___________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinf= o/dime