Subject: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded

From: Marco Liebsch <[email-masked]>
Date: Tue, 10 Apr 2012 14:06:54 +0000

Thanks for the meeting minutes. 

As the notes refer to a discussion about different means to signal bulk operation,
let's go through this exercise and evaluate the three candidates to signal
bulk commands.

Just to summarize the three alternatives according to Mark's presentation:
(a) New group commands
(b) Re-use existing commands and command codes, indicate group operation
on the attached context (AVPs) within the message, e.g. by adding group
identifier, flags, ..
(c) Single new bulk command (1 new command code), indicate Diameter command,
to which the group operation applies, within the message

Whereas I see (a) as straight forward method, a counterargument could be the
need of additional command codes for each command, which should be enabled
for group operation. Other SDOs, which specify new command codes, need
to follow the same rules and request new command codes for all existing commands
which should be bulk-operation enabled.

With (b), all existing messages could be re-used and potentially bulk operation enabled
by using a different application ID and adding an additional label to the message, e.g.
flags, Group session AVP, etc. Such approach allows much flexibil8ity, but we need
to ensure  compatibility with proxies etc, which are not bulk-operation enabled.
Possibly using a new application ID solves that issue already.

With (c), the DIME WG could specify a single dedicated command for bulk operations,
and the actual payload carries the command code of the Diameter message to be
executed as bulk operation (e.g. RAR, STR, ..) as well as the associated command's
AVP, plus a group identifier. Any existing and new command, which is so far used
for single session operations, can be bulk operation enabled. Formatting of such
bulk operation message is still open, maybe it has impact to existing applications'
command parser. If we find a suitable encoding scheme for such container message,
it's a concept that can be easily adopted by any Diameter command and application.

We'd be interested in more opinions about the different approaches and I hope that
this eMail can trigger such discussion.

marco

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> jouni korhonen
> Sent: Dienstag, 10. April 2012 11:53
> To: [email-masked]
> Subject: [Dime] very drafty IETF#83 meeting minutes uploaded
> 
> Folks,
> 
> They are up now for public review. Thanks to Shwetha for taking excellent
> minutes.
> 
> - Jouni
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Apr 2012 13:06:30 +0800

Hi, Marco:
I think the criteria we need to consider are:
how much protocol extension is really required?
how much such protocol affects the existing implementaion?
How many command exchanges can we reduce?
please see my comments inline.

Regards!
-Qin
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "jouni korhonen" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 10, 2012 10:06 PM
Subject: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded

> which should be bulk-operation enabled.

[Qin]: Agree. One more thing I am thinking is how to use existing Command Code can handle
group assigment. It looks to me additional semantics in these existing Command  are needed to 
distinguish adding a session into group from removing a sesion into group or distinguish group
 assignment from bulk signaling operation. 
New Command flags may be example of such additional semantics but seems not compelling.:-)

> Possibly using a new application ID solves that issue already.

[Qin]: I am not sure proxy in between needs to be bulk-operation enabled.
It looks to me bulk operation only happens on the source and final destination 
of the Diameter message.

> it's a concept that can be easily adopted by any Diameter command and application.

[Qin]: With the approach (c), is the proposal here using nested Command Codes, i.e., encapsulate 
or group existing command codes into one logical container. The logical container is still a command code. 
If the answer is yes, I am thinking why we should carry the existing command codes belonging to different user  or the same user that needs bulk operation
into one dedicated command code? Is it for a group of user or a single user?

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 11 Apr 2012 13:09:21 +0000

Hi Qin,
please see inline.

> From: Qin Wu [mailto:[email-masked]]
> Sent: Mittwoch, 11. April 2012 07:06
> To: Marco Liebsch; jouni korhonen; [email-masked]
> Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty
> IETF#83 meeting minutes uploaded
> 
> Hi, Marco:

The list of criteria sounds reasonable to me.

> New Command flags may be example of such additional semantics but

IMO, join/leave of a session to/from one or multiple groups should be treated
separately from bulk commands. 

> It looks to me bulk operation only happens on the source and final

What if a proxy receives a bulk command, which carries a new application ID? 
>From operation it should not bother, I agree, as per-session and group operations
are end-to-end. If implementations process the command code or application ID,
then compatibility may depend on how proxies or relay agents treat such messages.

> If the answer is yes, I am thinking why we should carry the existing command
> codes belonging to different user  or the same user that needs bulk
> operation

The idea was to have a single command code for bulk operations, which is
referred to in the Diameter header. I did 'not' consider having the complete
Diameter header twice, for the bulk command and for the Diameter command,
which is to be executed as bulk operation. So we may keep one Diameter header,
which carries the bulk command code, a single new AVP, which carries the Diameter
command (RAR, STR, ..), and the required attributes for group identification
and the AVPs, that apply to the group. So, I did not have nesting in mind.

marco

---

From: <[email-masked]>
Date: Wed, 11 Apr 2012 17:01:02 +0200

> then compatibility may depend on how proxies or relay agents treat such messages.

[LM] I think that the point is that the solution could be transparent to proxy if you can reuse existing applications without major impacts and not updating the application-Id. Of course, if you have to use a new application-id, any proxy will have to advertize the new application, as per definition of a proxy, even if the proxy is transparent to bulk operations.

Regards,

Lionel 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Marco Liebsch
Envoyé : mercredi 11 avril 2012 15:09
À : Qin Wu; jouni korhonen; [email-masked]
Objet : Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded

Hi Qin,
please see inline.

marco

---

From: Mark Jones <[email-masked]>
Date: Wed, 11 Apr 2012 12:10:28 -0400

Hi Marco,

Thanks for kicking off this thread. Some comments inline.

> which should be bulk-operation enabled.

Agreed but I don't think this is particularly onerous. SDOs no longer
need to write an RFC to get new command codes. A simple request to
IANA gets a vendor-specific command code.

> Possibly using a new application ID solves that issue already.

I understood this proposal as defining a new command flag in the
Diameter header to indicate that it was a grouped command. I think a
new application id is required regardless. I think a new command flag
will have more impact on existing Diameter stacks than (a) or (c)
where the grouped semantics are handled at the application layer.

> it's a concept that can be easily adopted by any Diameter command and application.

This proposal definitely economizes command codes but they are not a
scarce resource nor difficult to obtain.
Can you elaborate on why this can be more "easily adopted" because I
do not see a reduction in specification or implementation effort? If
existing commands are simply re-packaged as a grouped AVP, what does
one do with those required AVPs that are per-session, e.g. User-Name,
Session-Id? Specification text will be required to describe how these
surplus AVPs are to be treated. With proposal (a), these surplus AVPs
are simply omitted and the ABNF describes the new command structure. I
also have doubts that all commands can be re-packaged as a grouped
command so specification text will still be required to describe which
commands can be grouped and their associated semantics.

> this eMail can trigger such discussion.

Agreed. It would be good to hear some new voices on the list. We
discussed these three options in Paris but this is certainly not a
closed list. New proposals are also welcome.

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Apr 2012 16:29:10 +0800

Hi, Marco,
I have a few followup comments.

Regards!
-Qin
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "jouni korhonen" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 11, 2012 9:09 PM
Subject: RE: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded

Hi Qin,
please see inline.

[Qin]:Yes.

[Qin]: Yes, proxies and relay agents should understand the message if any new command code 
or any new application ID is defined. This can be done by Capability Exchange.

Another point is proxies may not need to look into message and
deep parse the payload of the message.
e.g., if we have new AVP, do you think proxy also need to parse this AVP?

[Qin]:  So your proposal is define one new container AVP to Carry all the code of  commands that need
bulk operation. This AVP can be used to inform the receiver of the message that these commands codes
need bulk operation. am I right?
In that case, it looks to me bulk command code is not redundant since you can use another new AVP that
carries group identifier to indicate this is for bulk operation. what am I missing?

marco

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Apr 2012 16:29:54 +0800

Agree.
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 11, 2012 11:01 PM
Subject: RE: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded

Regards,

Lionel 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Marco Liebsch
Envoyé : mercredi 11 avril 2012 15:09
À : Qin Wu; jouni korhonen; [email-masked]
Objet : Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded

Hi Qin,
please see inline.

marco

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Apr 2012 17:12:08 +0800

s/bulk command code is not redundant /bulk command code is  redundant
:-)

Regards!
-Qin

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 20 Apr 2012 12:27:19 +0000

Hi Qin,
finally coming back to this discussion.. please see inline.

> Sent: Donnerstag, 12. April 2012 10:29
> To: "Qin Wu" <[email-masked]>; "jouni korhonen"
> <[email-masked]>; <[email-masked]>
> > Subject: [Dime] discuss encoding of bulk commands /RE: very drafty
> IETF#83
> > meeting minutes uploaded
> >
> >
> > > Whereas I see (a) as straight forward method, a counterargument could
> be
> > the
> > distinguish adding a session into group from removing a sesion into group
> or
> > distinguish group

Hmm, compared to a relay, a proxy could process (I guess even touch/modify) command
payload. Now, a new application ID and new command codes would require the
proxy to support the new application. If we don't change the application ID and re-use
existing command codes for bulk signaling, a positive aspect could be to keep bulk
operations end-to-end and transparent to relays and proxies. The negative aspect
could be that a proxy assumes the command is meant for a single user session and
tries to process or even modify the group command's AVPs as it would do for single
session commands.

> > > and the actual payload carries the command code of the Diameter
> message
> > to be
> > > AVP, plus a group identifier. Any existing and new command, which is so
> far
> > used
> > > for single session operations, can be bulk operation enabled. Formatting
> of
> > such
> > > command parser. If we find a suitable encoding scheme for such
> container
> > message,

Not really. The proposal is to use a new command code for the container
and within that container, as further single command code is added,
which indicates for example a RAR command. Then the command comprises
a group ID and further AVPs. Hence, the application knows from the
group container command code that the command referred to inside
is a bulk operation. Then a RAR applies to all sessions being part of the
group. 

Is your concern that having a group identifier plus a bulk command code is
redundant? I think it depends at which level of the stack processing we
want the Diameter function to know about single session or bulk
operation. More important, we need to avoid failures due to wrong
processing.

If we want to avoid a new command code, we may again consider our
initial proposal to indicate bulk operation by means of a dedicated session ID,
which is not assigned to any single use session ;-) I think that's similar
to adding a flag. 

marco

> 
> 
> marco
> 
> >
> > > We'd be interested in more opinions about the different approaches and
> I
> > hope that
> > >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > >> jouni korhonen

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 20 Apr 2012 12:35:33 +0000

Hi Lionel,
please see inline.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Mittwoch, 11. April 2012 17:01
> To: Marco Liebsch; [email-masked]; [email-masked];
> [email-masked]
> > > > With (b), all existing messages could be re-used and potentially
> > > > bulk
> > > operation enabled
> > > > flags, Group session AVP, etc. Such approach allows much
> > > > flexibil8ity, but we need to ensure  compatibility with proxies
> > > > etc, which are not bulk-operation enabled.
> > > It looks to me bulk operation only happens on the source and final
> > > destination of the Diameter message.
> 
> > From operation it should not bother, I agree, as per-session and group
> > operations are end-to-end. If implementations process the command code
> > or application ID, then compatibility may depend on how proxies or relay
> agents treat such messages.
> 
> [LM] I think that the point is that the solution could be transparent to proxy if
> you can reuse existing applications without major impacts and not updating
> the application-Id. Of course, if you have to use a new application-id, any
> proxy will have to advertize the new application, as per definition of a proxy,
> even if the proxy is transparent to bulk operations.

Is the proposal to keep the application ID but use a new command code?
Or is the idea to keep the application ID and use existing command codes?
Then we have to be careful with proxies, I guess, who may access
commands under the assumption that it's a single session command,
and if it happens that the proxy modifies the message, then it should
not conflict with performing the group operation on the receiving endpoint.

marco

> De : [email-masked] [mailto:[email-masked]] De la part de
> Marco Liebsch Envoyé : mercredi 11 avril 2012 15:09 À : Qin Wu; jouni
> korhonen; [email-masked] Objet : Re: [Dime] discuss encoding of bulk
> commands /RE: very drafty IETF#83 meeting minutes uploaded
> 
> Hi Qin,
> please see inline.
> 
> > > As the notes refer to a discussion about different means to signal
> > > bulk
> > operation,
> > > let's go through this exercise and evaluate the three candidates to
> > > signal bulk commands.
> > >
> > > on the attached context (AVPs) within the message, e.g. by adding
> > > group identifier, flags, ..
> > > Whereas I see (a) as straight forward method, a counterargument
> > > could be
> > the
> > > for group operation. Other SDOs, which specify new command codes,
> > > need to follow the same rules and request new command codes for all
> > > existing
> > commands
> > [Qin]: Agree. One more thing I am thinking is how to use existing
> > Command Code can handle group assigment. It looks to me additional
> > semantics in these existing Command  are needed to distinguish adding
> > a session into group from removing a sesion into group or distinguish
> > group  assignment from bulk signaling operation.
> IMO, join/leave of a session to/from one or multiple groups should be
> treated separately from bulk commands.
> 
> >
> > > With (b), all existing messages could be re-used and potentially
> > > bulk
> > operation enabled
> > > by using a different application ID and adding an additional label
> > > to the
> > message, e.g.
> > > flags, Group session AVP, etc. Such approach allows much
> > > flexibil8ity, but
> > we need
> > > to ensure  compatibility with proxies etc, which are not
> > > bulk-operation
> > enabled.
> > It looks to me bulk operation only happens on the source and final
> > destination of the Diameter message.
> 
> From operation it should not bother, I agree, as per-session and group
> operations are end-to-end. If implementations process the command code
> or application ID, then compatibility may depend on how proxies or relay
> agents treat such messages.
> 
> 
> >
> > > With (c), the DIME WG could specify a single dedicated command for
> > > bulk
> > operations,
> > > executed as bulk operation (e.g. RAR, STR, ..) as well as the
> > > associated
> > command's
> > > AVP, plus a group identifier. Any existing and new command, which is
> > > so far
> > used
> > > for single session operations, can be bulk operation enabled.
> > > Formatting of
> > such
> > > bulk operation message is still open, maybe it has impact to
> > > existing
> > applications'
> > > it's a concept that can be easily adopted by any Diameter command
> > > and
> > application.
> >
> > [Qin]: With the approach (c), is the proposal here using nested
> > Command Codes, i.e., encapsulate or group existing command codes into
> > one logical container. The logical container is still a command code.
> > If the answer is yes, I am thinking why we should carry the existing
> > command codes belonging to different user  or the same user that needs
> > bulk operation into one dedicated command code? Is it for a group of
> > user or a single user?
> 
> Diameter header twice, for the bulk command and for the Diameter
> command, which is to be executed as bulk operation. So we may keep one
> Diameter header, which carries the bulk command code, a single new AVP,
> which carries the Diameter command (RAR, STR, ..), and the required
> attributes for group identification and the AVPs, that apply to the group. So, I
> did not have nesting in mind.
> 
> marco
> 
> >
> > > We'd be interested in more opinions about the different approaches
> > > and I
> > hope that
> > >> They are up now for public review. Thanks to Shwetha for taking
> > >> excellent minutes.
> > >>
> > >> - Jouni