Subject: Re: [Dime] Diameter Overload - Conveying Load/Overload informatio iin Connection messages

From: Thierry Bessis <[email-masked]>
Date: Mon, 05 Aug 2013 12:36:56 +0200

All,

Sorry to react so late: I was on vacation.

We understand that using DWR/DWA would allow a client to know "in 
advance" the overload state of a remote server that it does not use 
currently.
However, with the "normal transaction based" mechanism, the overload 
information would be acquired almost immediately as it takes only a 
single completed transaction to get the overload feedback that is needed 
to shed (or do any other appropriate action).
Another important consideration is that the overload information that 
would convey the DWR/DWA would (of course) not take into account the 
(coming) new traffic, so it would be in essence completely wrong and 
late regarding the new condition. More accurate seems to be a mechanism 
that allows in real time and continuously the feedback information to 
flow, such as one using the transactions themselves.

Finally, the DWR/DWA load information must support many additional scope 
information (unlike when transactiosn are used) because a single 
connection may be used by all sorts of flows. Given the very 
questionable "advantage" that using connection based messages provided, 
this is a complication that does not seem to be needed.

Cordially,

Thierry

On 16-Jul-2013 16:09, Steve Donovan wrote:
> 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
>
> On Jul 16, 2013, at 6:48 AM, Eric McMurry <[email-masked]> wrote:
>
>> Hi JJacques,
>>
>>
>> On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> wrote:
>>
>>> 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
>> 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 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.
>>>
>> 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
>>
>>
>>
>>> 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
>>>
>>>
>>> On Jul 14, 2013, at 9:40 AM, Eric McMurry <[email-masked]> wrote:
>>>
>>>> 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.
>>> 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.
>>>
>>>
>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>
>>>>
>>>> On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C" <[email-masked]> wrote:
>>>>
>>>>> 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]
>>>>> +1-609-903-3360
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime

-- 
Thierry's signature

**

*--
Cordially,
Thierry Bessis*

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

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

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

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

*Upcoming planned Trips and Vacations: *

*9 Jul -- 5 Aug 2013: Vacations *

---

From: Eric McMurry <[email-masked]>
Date: Mon, 5 Aug 2013 14:51:01 +0200

Hi Thierry,

Welcome back :-)

DWR/DWA support (at least in the roach draft) was there to support quiescent connections.  I'm guessing from your questions that you are thinking it was the only way to send overload information?  That draft uses all messages and has the rapid characteristic you call out.  The scope of information wasn't any different with DWR/DWA or any other messages.

Thanks,

Eric

On Aug 5, 2013, at 12:36 , Thierry Bessis <[email-masked]> wrote:

> We understand that using DWR/DWA would allow a client to know "in advance" the overload state of a remote server that it does not use currently. 
> However, with the "normal transaction based" mechanism, the overload information would be acquired almost immediately as it takes only a single completed transaction to get the overload feedback that is needed to shed (or do any other appropriate action). 
> Another important consideration is that the overload information that would convey the DWR/DWA would (of course) not take into account the (coming) new traffic, so it would be in essence completely wrong and late regarding the new condition. More accurate seems to be a mechanism that allows in real time and continuously the feedback information to flow, such as one using the transactions themselves. 
> 
> Finally, the DWR/DWA load information must support many additional scope information (unlike when transactiosn are used) because a single connection may be used by all sorts of flows. Given the very questionable "advantage" that using connection based messages provided, this is a complication that does not seem to be needed. 
> 
> Cordially, 
> 
> Thierry
> 
> Thierry Bessis
>  N1 146.5   Alcatel-Lucent France Lieu Dit Le Mail
>  44708 ORVAULT France
> SARB Site: http://all.alcatel-lucent.com/wps/portal/cf/research/network_tech_strat/sarb
> Upcoming planned Trips and Vacations:
> 9 Jul – 5 Aug 2013: Vacations

---

From: Eric McMurry <[email-masked]>
Date: Tue, 6 Aug 2013 16:38:43 +0200

Hi Thierry,

Thanks for the clarification.  Comments inline.

Eric

On Aug 6, 2013, at 16:14 , Thierry Bessis <[email-masked]> wrote:

> Thanks Eric ! 
> 
> I know the transaction based method is also supported by the Roach draft. 
> We are advocating for a much simpler base overload mechanism where only the transaction method with its default scope is (be default) supported (The default scope does not need any explicit scope, since the scope is determined by the transaction context itself). (Note: Our proposal is that some additional explicit scopes could be added later as an extension if needed, but not in the base mechanism), 

well, the scopes are for other purposes besides supporting use of DWR/DWA (may not be able to meet granular control requirements without them).

> What I was trying to explain is that using the DWR/DWA method does not seem to add so much value that it should be included in the base protocol (Since the transaction based based method would be required anyway). Since using DWR/DWA would inevitably require explicit scopes (such as those introduced by Roach), it would complicate unnecessary the base protocol that does not need any explicit scope otherwise.

I agree that using DWR/DWA is not that important.  You can solve the quiescent connection issue in a couple of different ways.  For example, you can forbid links being shut down completely, or you can use a dedicated application for transporting overload control information (note that this would also require explicit scopes).

> In case the DRA used to hide the server's host name and we want the client to participate in the shedding (which makes sense), it would make more sense to ask the DRA (that will need for overload control extensive code change anyway) to stop doing that, rather than hiding the information in the origin-host AVP, and then re-including this information in a specific new "host scope" AVP. 

I'm afraid you lost me on this.  How is DRA used for host name hiding?

> 
> Cordially, 
> 
> Thierry
> 
> 
> On 05-Aug-2013 14:51, Eric McMurry wrote:
>> Hi Thierry,
>> 
>> Welcome back :-)
>>

---

From: Thierry Bessis <[email-masked]>
Date: Tue, 06 Aug 2013 16:14:33 +0200

Thanks Eric !

I know the transaction based method is also supported by the Roach draft.
We are advocating for a much simpler base overload mechanism where only 
the transaction method with its default scope is (be default) supported 
(The default scope does not need any explicit scope, since the scope is 
determined by the transaction context itself). (Note: Our proposal is 
that some additional explicit scopes could be added later as an 
extension if needed, but not in the base mechanism),
What I was trying to explain is that using the DWR/DWA method does not 
seem to add so much value that it should be included in the base 
protocol (Since the transaction based based method would be required 
anyway). Since using DWR/DWA would inevitably require explicit scopes 
(such as those introduced by Roach), it would complicate unnecessary the 
base protocol that does not need any explicit scope otherwise.
In case the DRA used to hide the server's host name and we want the 
client to participate in the shedding (which makes sense), it would make 
more sense to ask the DRA (that will need for overload control extensive 
code change anyway) to stop doing that, rather than hiding the 
information in the origin-host AVP, and then re-including this 
information in a specific new "host scope" AVP.

Cordially,

Thierry

On 05-Aug-2013 14:51, Eric McMurry wrote:
> Hi Thierry,
>
> Welcome back :-)
>
> DWR/DWA support (at least in the roach draft) was there to support 
> quiescent connections.  I'm guessing from your questions that you are 
> thinking it was the only way to send overload information?  That draft 
> uses all messages and has the rapid characteristic you call out.  The 
> scope of information wasn't any different with DWR/DWA or any other 
> messages.
>
> Thanks,
>
> Eric
>
>
> On Aug 5, 2013, at 12:36 , Thierry Bessis 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> All,
>>
>> single completed transaction to get the overload feedback that is 
>> needed to shed (or do any other appropriate action).
>> late regarding the new condition. More accurate seems to be a 
>> mechanism that allows in real time and continuously the feedback 
>> information to flow, such as one using the transactions themselves.
>>
>> Finally, the DWR/DWA load information must support many additional 
>> scope information (unlike when transactiosn are used) because a 
>> single connection may be used by all sorts of flows. Given the very 
>> questionable "advantage" that using connection based messages 
>> provided, this is a complication that does not seem to be needed.
>>
>> Cordially,
>>
>> Thierry
>>
>>> On Jul 16, 2013, at 6:48 AM, Eric McMurry<[email-masked]>  wrote:
>>>
>>>> Hi JJacques,
>>>>
>>>>
>>>> On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"<[email-masked]>  wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> De :[email-masked]  [mailto:[email-masked]] De la part de Ben Campbell
>>>>> Cc :[email-masked]
>>>>> On Jul 14, 2013, at 9:40 AM, Eric McMurry<[email-masked]>  wrote:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> On Jul 14, 2013, at 7:59 , "DOLLY, MARTIN C"<[email-masked]>  wrote:
>>>>>>
>>>>>>> Ben,
>>>>>>>
>> *9 Jul – 5 Aug 2013: Vacations *
>>
>

-- 
Thierry's signature

**

*--
Cordially,
Thierry Bessis*

Conference information:

*9 Jul – 5 Aug 2013: Vacations *