Subject: [Dime] Diameter overload vs. bulk signaling

From: Marco Liebsch <[email-masked]>
Date: Mon, 18 Feb 2013 15:44:00 +0000

Folks,

the DIME WG has a work item on bulk signaling, which is related to the overload
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 signaling 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 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/minutes/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

---

From: <[email-masked]>
Date: Mon, 18 Feb 2013 16:01:52 +0000

Hi,

As an individual, I support the 3rd approach, reusing existing commands. But it is not a surprise as I was one of the defender of this approach during the meeting.

Regards,

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Marco Liebsch
Envoyé : lundi 18 février 2013 16:44
À : [email-masked]
Objet : [Dime] Diameter overload vs. bulk signaling

Folks,

Brief recap:

Cheers,

marco

_________________________________________________________________________________________________________________________

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

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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 19 Feb 2013 14:48:29 +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 protocols,
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: [email-masked] [mailto:[email-masked]]
>Sent: Montag, 18. Februar 2013 17:02
>To: Marco Liebsch; [email-masked]
>Subject: RE: Diameter overload vs. bulk signaling
>
>Hi,
>
>
>
>As an individual, I support the 3rd approach, reusing existing commands. But it is
>not a surprise as I was one of the defender of this approach during the meeting.
>
>
>
>Regards,
>
>
>
>Lionel
>
>
>
>De : [email-masked] [mailto:[email-masked]] De la part de
>Marco Liebsch Envoyé : lundi 18 février 2013 16:44 À : [email-masked] Objet :
>[Dime] Diameter overload vs. bulk signaling
>
>
>
>Folks,
>
>study in that it can help mitigating overload; mainly on the network paths
>between diameter peers.
>
>
>
>At IETF84 we discussed two technical approaches to enable Diameter signaling
>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 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/minutes/minutes-84-dime).
>
>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,
>_________________________________________________________________
>________________________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
>copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
>signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration, France Telecom - Orange decline
>toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law; they should not be distributed, used
>or copied without authorisation.
>As emails may be altered, France Telecom - Orange is not liable for messages
>that have been modified, changed or falsified.
>Thank you.