Subject: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01

From: jouni korhonen <[email-masked]>
Date: Sun, 1 Apr 2012 22:20:27 +0300

Folks,

During the Dime WG meeting in Paris we decided to adopt draft-jones-diameter-group-signaling-01
"Diameter Group Signaling" as a working group I-D. The I-D is an input for the charter mile stone
'Protocol extension for bulk and group signaling'.

This mail starts a one week verification for the adoption. If you have strong concerns that the 
draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_ for the solution, then
express your concerns on the mailing list by 8th April.

- Jouni & Lionel

---

From: Tina TSOU <[email-masked]>
Date: Wed, 4 Apr 2012 23:41:26 +0000

Hi Jouni and Mark,
The problem statement is valid and the solution can work in basic scenarios. 
   
However the solution may have some limit in roaming scenario.
 
Consider a network having a WLAN AN (hosting a Diameter Client) requesting some 3G internet resources, visited network proxies and home network server as below:
 
Client -------------- <Visited n/w proxy 1> ---------- {Home network server}
         -------------- <Visited n/w proxy 2> ----------{Home network server}

The session path can be established through either of the visited n/w proxies. For all the messages of same session, client can ensure that the session path through stateful nodes is maintained. The visited n/w proxies would require that the session path be maintained for offline charging etc.
In this scenario, if client uses group signalling method to terminate all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will be aware of session termination. Since there are no follow-up messages, there is no mechanism to let the other proxy know that the sessions are terminated.
This problem can be avoided in Server initiated group signalling cases (GRAR & GASR) as the PER_SESSION mode can be used for follow up exchanges.
Thus the current solution has a limit if client uses group signalling method for session termination in roaming cases.

I volunteer to work together with Mark to find a solution for this case.

I'm NOT aware of any IPR in this area.

Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> jouni korhonen
> Sent: Sunday, April 01, 2012 12:20 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group-
> signaling-01
> 
> 
> Folks,
> 
> "Diameter Group Signaling" as a working group I-D. The I-D is an input for
> the charter mile stone 'Protocol extension for bulk and group signaling'.
> 
> draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_
> for the solution, then express your concerns on the mailing list by 8th
> April.
> 
> - Jouni & Lionel
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Mark Jones <[email-masked]>
Date: Wed, 11 Apr 2012 11:09:49 -0400

Hi Tina,

I agree that the role of a proxy in group signalling has not been
explored in the current draft and appreciate your offer to work on
this aspect. Further comments inline.

> The session path can be established through either of the visited n/w proxies. For all the messages of same session, client can ensure that the session path through stateful nodes is maintained. Th…

In your example, I understand from "session path" that you're assuming
the client will ensure that the STR traverses the same visited n/w
proxy so that state is cleaned up in the appropriate proxy, right?

> In this scenario, if client uses group signalling method to terminate all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will be aware of session termination. Since there are…

If the client knows the session path for each session then it knows
that both visited n/w proxies need to receive the GSTR. However, if
the client sends the GSTR to both proxies then the home n/w server is
going to get two GSTR for the same group from the same origin host.
Yuck!

Since groups assignments are arbitrary, the client could create a
subgroup per session path and send the subgroup GSTR to the
appropriate proxy. Path failures would make the error handling very
complex though.

> This problem can be avoided in Server initiated group signalling cases (GRAR & GASR) as the PER_SESSION mode can be used for follow up exchanges.

It could also be avoided in the GSTR case. If the client knows that
the group termination will impact sessions that have session paths
split across multiple proxies then it MUST revert to per-session STR
signaling. However, I'd much prefer to solve this if we can.

> Thus the current solution has a limit if client uses group signalling method for session termination in roaming cases.

Agreed.

> I volunteer to work together with Mark to find a solution for this case.

Great!

> I'm NOT aware of any IPR in this area.

Me neither.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 12 Apr 2012 05:34:29 +0000

> From: Mark Jones [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2012 8:10 AM
> To: Tina TSOU
> Cc: jouni korhonen; [email-masked]; [email-masked]
> Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-
> signaling-01
> 
> Hi Tina,
> 
> > Consider a network having a WLAN AN (hosting a Diameter Client)
> requesting some 3G internet resources, visited network proxies and home
> network server as below:
> >
> > The session path can be established through either of the visited n/w
> proxies. For all the messages of same session, client can ensure that
> the session path through stateful nodes is maintained. The visited n/w
> proxies would require that the session path be maintained for offline
> charging etc.
> 
Right.
> 
> > In this scenario, if client uses group signalling method to terminate
> all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path
> will be aware of session termination. Since there are no follow-up
> messages, there is no mechanism to let the other proxy know that the
> sessions are terminated.
> 
Yuck indeed!
> appropriate proxy. Path failures would make the error handling very
It is a problem of scale. If there is only 1 visited n/w involved, this approach is OK. If there are more than one, (for eg. a HK CSL user in roaming in India may need to connect to their home network through more than one visited networks in the session path) client may not have enough information to create sub groups appropriately.
> 
> > This problem can be avoided in Server initiated group signalling cases
> (GRAR & GASR) as the PER_SESSION mode can be used for follow up
> exchanges.
> 
Since it is not possible for the client to have complete information about the roaming topology, this would limit the client to always revert to per-session STR in all roaming cases.
> 
> > Thus the current solution has a limit if client uses group signalling
> method for session termination in roaming cases.
> >
> 
> Agreed.
> 
> >> This mail starts a one week verification for the adoption. If you
> have
> >> strong concerns that the

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 Apr 2012 12:02:46 +0300

Tina,

> In this scenario, if client uses group signalling method to terminate all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will be aware of session termination. Since there are…

How this differentiates from a generic issue where someone
puts a proxy on path that is supposed to stay on path and
at the same time allows by deployment options an alternative
path to take place? Like asking for trouble..

> Thus the current solution has a limit if client uses group signalling method for session termination in roaming cases.

The problem could also be avoided by not doing such deployment
where this can happen.

- Jouni

---

From: <[email-masked]>
Date: Thu, 12 Apr 2012 11:35:36 +0200

Hi Jouni, Tina and Mark,

I share the Jouni's point of view. If stateful proxies are required in the path, all messages related to the same sessions have to go through the same proxy.

If an implementation allows relying on multiple stateful proxies to manage the same sessions, this implementation needs also to support a mechanism ensuring a consistent management of the session data contexts between proxies. But IMHO, this kind of implementation is and should remain out of scope of any Diameter protocol spec.

Regards,

Lionel

-----Message d'origine-----
De : jouni korhonen [mailto:[email-masked]] 
Envoyé : jeudi 12 avril 2012 11:03
À : Tina TSOU
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01

Tina,

- Jouni

---

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Apr 2012 17:29:42 +0000

Sent from my iPad

> Tina,
Thank u, Jouni. Comments are in line.
> path to take place? Like asking for trouble..
The problem I am trying to put forth is one where the sessions between a client and server can take more than one path, but the group session termination signalling (GSTR) can take only one of such path. This is different from other group signalling exchanges suggested where there is a followup (GRAR, GASR etc.) which can be done at PER_SESSION level.

---

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Apr 2012 17:33:41 +0000

Sent from my iPad

> Hi Jouni, Tina and Mark,
Merci, Lionel. Comments r in line.
> I share the Jouni's point of view. If stateful proxies are required in the path, all messages related to the same sessions have to go through the same proxy.
You are right. Implementations should ensure this. However in group signalling only one (req-resp pair) group signalling message is exchanged between the client and the server. It can only take one of the session path between the client and the server. For server-initiated group signaling, implementations can still ensure "maintaining" the session path by indicating the follow up to happen at PER_SESSION level. The client initiated group signalling has no such provision in the current solution.

---

From: jouni korhonen <[email-masked]>
Date: Fri, 13 Apr 2012 22:35:36 +0300

Tina,

On Apr 13, 2012, at 8:33 PM, Tina TSOU wrote:

> You are right. Implementations should ensure this. However in group signalling only one (req-resp pair) group signalling

I would still day.. "deployments should ensure this". This is a generic
issue.

>  message is exchanged between the client and the server. It can only take one of the session path between the client and the server. For server-initiated group signaling, implementations can still ensure "maintaining" the session path by 

If a specific deployment requires that a specific node is always on path
that must not be different then from whether the message exchange is 
initiated by the client or the server.

- Jouni

> indicating the follow up to happen at PER_SESSION level. The client initiated group signalling has no such provision in the current solution.
>>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Apr 2012 22:54:59 +0000

Sent from my iPad

> Tina,
Thank u Jouni.