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

> -----Original Message-----
> From: Mark Jones [mailto:mark@azu.ca]
> Sent: Wednesday, April 11, 2012 8:10 AM
> To: Tina TSOU
> Cc: jouni korhonen; dime@ietf.org; dime-chairs@tools.ietf.org
> Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-
> signaling-01
> 
> 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.
> 
> On Wed, Apr 4, 2012 at 7:41 PM, Tina TSOU <Tina.Tsou.Zouting@huawei.com>
> wrote:
> > 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 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?
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.
> 
> 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!
Yuck indeed!
> 
> 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.
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.
> 
> 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.
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.
> 
> > 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.
> 
> >
> > Tina
> >
> >
> >> -----Original Message-----
> >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf
> Of
> >> jouni korhonen
> >> Sent: Sunday, April 01, 2012 12:20 PM
> >> To: dime@ietf.org
> >> Cc: dime-chairs@tools.ietf.org
> >> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group-
> >> signaling-01
> >>
> >>
> >> 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
> >>
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dime