Thierry's signature

dime-bounces@ietf.org wrote on 08/01/2013 07:57:43
AM:

> From: Jouni Korhonen <jouni.nospam@gmail.com>
> To: dime@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>,

> Marco Liebsch <marco.liebsch@neclab.eu>, "Zhouqian (Cathy)"

> <cathy.zhou@huawei.com>
> Date: 08/01/2013 07:58 AM
> Subject: Re: [Dime] IETF87 meeting logistics
> Sent by: dime-bounces@ietf.org
> 

> 

> On Jul 24, 2013, at 10:25 PM, Jouni Korhonen <jouni.nospam@gmail.com>
wrote:

> 

> > 

> > 

> > 2) Those who are on the agenda, please send your slides to the
chairs

> > by Thursday 1st Aug 1PM..

> 

> 

> We are still lacking quite many presentations.

> 

> - JOuni & Lionel

> 

> 

> > 

> > 

> > - Jouni & Lionel

> 

> _______________________________________________

> DiME mailing list

> DiME@ietf.org

> 
https://www.ietf.org/mailman/listinfo/dime

   The term "redirect server" denotes the device that returns the realm-
   based redirection.  It replaces "redirect agent" in this context for
   reasons explained in the next section.
   However, despite the change in
   executing role, the behaviour itself is a slight modification of the
   behaviour of a redirect agent as described in Section 2.8.3 of
   [RFC6733].
Abstract

   The Diameter protocol allows a Diameter redirect agent to return to
   the message sender one or more individual hosts as destinations of
   the redirected message.  However,
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

______________________________________________________________________=
___________________________________________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

<lionel.morand@orange.com> wrote on 08/02/2013
05:37:10 AM:

> From: <lionel.morand@orange.com>
> To: Janet P Gunn/USA/CSC@CSC, "dime@ietf.o=
rg"
<dime@ietf.org>
> Date: 08/02/2013 05:37 AM
> Subject: RE: [Dime] Hannes slides?
> 

> Right now
>  
> De : dime-bounces@ietf.org [
mailto:dime-bounces@ie=
tf.org
]
De la part de

> Janet P Gunn

> Envoy=E9 : vendredi 2 ao=FBt 2013 11:37

> =C0 : dime@ietf.org

> Objet : [Dime] Hannes slides?
>  
> Is there any chance of getting Hannes's slides
uploaded before his 

> presentation? 

> 

> Would be much appreciated by this remote user. 

> 

> Janet

> 

> This is a PRIVATE message. If you are not the intended recipient,

> please delete without copying and kindly advise us by e-mail of the

> mistake in delivery. NOTE: Regardless of content, this e-mail shall

> not operate to bind CSC to any order or other contract unless 

> pursuant to explicit written agreement or government initiative 

> expressly permitting the use of e-mail for such purpose.
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F

> 

> Ce message et ses pieces jointes peuvent contenir des informations

> confidentielles ou privilegiees et ne doivent donc

> pas etre diffuses, exploites ou copies sans autorisation. Si vous

> avez recu ce message par erreur, veuillez le signaler

> a l'expediteur et le detruire ainsi que les pieces jointes. Les 

> messages electroniques etant susceptibles d'alteration,

> Orange decline toute responsabilite si ce message a ete altere, 

> deforme ou falsifie. Merci.

> 

> This message and its attachments may contain confidential or 

> privileged information that may be protected by law;

> they should not be distributed, used or copied without authorisation.<=
br>
> If you have received this email in error, please notify the sender

> and delete this message and its attachments.

> As emails may be altered, Orange is not liable for messages that 

> have been modified, changed or falsified.

> Thank you.

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 <emcmurry@computer.org> wrote:

Hi JJacques,

On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@ALCATEL-LUCENT.COM> 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 : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : dimanche 14 juillet 2013 19:57
À : Eric McMurry
Cc : dime@ietf.org
Objet : Re: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages

On Jul 14, 2013, at 9:40 AM, Eric McMurry <emcmurry@computer.org> 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" <md3135@att.com> 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
md3135@att.com
+1-609-903-3360

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

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 <emcmurry@computer.org> =
wrote:

Hi JJacques,

On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.t=
rottin@ALCATEL-LUCENT.COM> 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=20

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=20

-----Message d'origine-----
De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] =
De la part de Ben Campbell
Envoy=E9 : dimanche 14 juillet 2013 19:57
=C0 : Eric McMurry
Cc : dime@ietf.org
Objet : Re: [Dime] Diameter Overload - Conveying Load/Overload =
information in Connection messages

On Jul 14, 2013, at 9:40 AM, Eric McMurry <emcmurry@computer.org> =
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" <md3135@att.com> 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
md3135@att.com
+1-609-903-3360

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime

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 <emcmurry@computer.org> =
wrote:

Hi JJacques,

On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.t=
rottin@ALCATEL-LUCENT.COM> 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=20

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=20

-----Message d'origine-----
De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] =
De la part de Ben Campbell
Envoy=E9 : dimanche 14 juillet 2013 19:57
=C0 : Eric McMurry
Cc : dime@ietf.org
Objet : Re: [Dime] Diameter Overload - Conveying Load/Overload =
information in Connection messages

On Jul 14, 2013, at 9:40 AM, Eric McMurry <emcmurry@computer.org> =
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" <md3135@att.com> 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
md3135@att.com
+1-609-903-3360

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dime

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 <emcmurry@computer.org> wrote:

Hi JJacques,

On Jul 16, 2013, at 4:11 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@ALCATEL-LUCENT.COM> 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 : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoy� : dimanche 14 juillet 2013 19:57
� : Eric McMurry
Cc : dime@ietf.org
Objet : Re: [Dime] Diameter Overload - Conveying Load/Overload information in Connection messages

On Jul 14, 2013, at 9:40 AM, Eric McMurry <emcmurry@computer.org> 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" <md3135@att.com> 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
md3135@att.com
+1-609-903-3360

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