Subject: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages

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

Ben,

Everyone agrees that load/overload information needs to be conveyed in Application level messages.

Under what circumstances  is there a benefit conveying the load/overload information in diameter Connection level messages (e.g., DRA, DRW)?

Thanks,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Labs
[email-masked]<mailto:[email-masked]>
+1-609-903-3360

---

From: Eric McMurry <[email-masked]>
Date: Sun, 14 Jul 2013 09:40:58 -0500

Hi Martin,

The main use of DWR/DWA for this would be quiescent connections.  Take a case where an overload condition has caused a server to request a complete traffic backoff.  Once that happens, until the timer on that overload control information pops, the clients won't send any traffic for scope encompassed by that backoff request.  If that server recovers before that backoff period, the client will still not send it any traffic.  Using a DWR though, the server can send new control information at any time, so that it could indicate to the client when it has recovered, so that traffic can begin flowing.  The real use of this is to ensure that links don't stay quiescent any longer than necessary.  The general difference though between using the watchdog messages vs. other applications is that they can be sent in an ad hoc fashion without side effects.

Thanks,

Eric

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

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

---

From: Ben Campbell <[email-masked]>
Date: Sun, 14 Jul 2013 12:56:31 -0500

> The main use of DWR/DWA for this would be quiescent connections.  Take a case where an overload condition has caused a server to request a complete traffic backoff.  Once that happens, until the ti…

I concur with this, but have a couple of additional points:

1) I don't think we want to restrict the sending of _initial_ overload info to active peers only. Imagine a pair of agents, where clients for one reason or another send all traffic over one, and use the other as a backup. If both agents have connections to a server, one of those connections may be effectively quiescent. If the server sends an overload report to the active server, clients may simply redirect traffic to the backup server, and cause that connection to become suddenly active.

2) The quiescent connection argument assumes that DWR/DWA don't _also_ get quenched by an overload report. I suspect we never want that to happen, and should make that explicit somewhere in the solution.

---

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

Hi

About the use of connection messages (DWR/DWA) to convey overload info, I do not yet foresee the use of DWR/DWA with overload info

- case of quiescent line, this seems quite theoretical, it would mean that when entering in overload conditions the server would block the whole traffic, this is not in line with the objective to maintain an optimal throughput. The server when generating overload info has to avoid to block the whole traffic 

- case of active stand-by:  in normal conditions (outside overload), a sending entity will not send traffic towards a stand by entity, except if the active receiving entity fails. If a part of traffic is redirected, it is no more an active / Standby but a load balancing case. Management of this type of situations (active, stand-by) is handled through other mechanism than the use of DWR/DWA with overload info.

Best regards

JJacques 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : dimanche 14 juillet 2013 19:57
À : Eric McMurry
Cc : [email-masked]
Objet : Re: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages

---

From: Eric McMurry <[email-masked]>
Date: Tue, 16 Jul 2013 06:48:16 -0500

Hi JJacques,

> - case of quiescent line, this seems quite theoretical, it would mean that when entering in overload conditions the server would block the whole traffic, this is not in line with the objective to m…

I agree that things have gone badly if this happens.  I'm not sure about it being theoretical though.  A server may chose to throttle some clients more than others and things do go rather badly on occasion.  Hopefully this mechanism would help keep things from getting to this point in most situations.

> - case of active stand-by:  in normal conditions (outside overload), a sending entity will not send traffic towards a stand by entity, except if the active receiving entity fails. If a part of traf…

The case for the backup being able to pick up the traffic falls down if the active was reporting overload because of some resource that was shared by both it and the backup.  Sending traffic to the backup will result in more overload then.

Is there a side effect of allowing overload control information on watchdogs that is undesirable?

Thanks!

Eric

---

From: Steve Donovan <[email-masked]>
Date: Tue, 16 Jul 2013 09:09:29 -0500

The active/standby scenario that would support the use of DWR/DWA is overload followed by failure of the active connection.  It would be best of the standby connection understood the overload state of the peer prior to becoming active so as to avoid contributing to the overload situation.

DWR/DWA is one way to address this situation.  Use of the Host scope would be another.

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Jul 2013 16:00:14 +0300

A meta question regarding the use of the DWR/DWA. Are we then OK universally assuming &
requiring RFC6733 as the minimum base protocol version for overload control solution? The
requirement draft assumes RFC6733 but how about external SDOs with their specifications
when it comes to overload solution?

- Jouni

---

From: Eric McMurry <[email-masked]>
Date: Thu, 18 Jul 2013 08:26:09 -0500

That's a good point Jouni, and is one that was called out in the draft as I recall.

It's hard to answer though.  The main consumer of this is likely to be 3gpp for R12.  Perhaps Lionel can comment on wether there is anything like an official decision on that there.  The main consumers of equipment supporting this will likely be operators.  I would think it is also relevant wether any of them plan to continue support of 3588 in the time frame this would become available.

At any rate, I don't think any of the cases for it show that things will break if it is not used, just that it will not work as well.  

thanks,

Eric