Subject: Re: [Dime] Summary of 3588bis Issues Status

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 04 Aug 2006 11:31:51 -0400

On Thu, Jul 27, 2006 at 08:02:12PM +0800, Tony Zhang wrote:
> Hi John:
> 	When I read proxy agent definition in RFC3588:
>    Proxies that wish to limit resources MUST maintain session state.
>    All proxies MUST maintain transaction state.
>    Since enforcing policies requires an understanding of the service
>    being provided, Proxies MUST only advertise the Diameter applications
>    they support.
> 
> Maybe almost the stateful proxy is more.
> 
> If With respect to the App ID = 0 issue, we assumed that
> proxies are stateless.
> I think use app Id = 0,the routing for some environment is not effective.
> Tolga already give one network environment.

On the other hand, use of App ID = 0 does not completely solve the
routing issue with stateful proxies, especially when there are
multiple candidate next hop stateful proxies.  In this case whatever
application id is used, it is not guaranteed that all messages that
belong to the same session to go through the same stateful proxy.  I
believe source routing is needed to solve the routing problem with
stateful proxies.

Yoshihiro Ohba

> 
> Thanks!
> Tony.
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 27, 2006 7:30 AM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Summary of 3588bis Issues Status
> 
> Tony,
> 
> During the initial work on Diameter, it was hoped that proxies would
> be a rare occurance.  We assumed all proxies will be stateless.
> 
> If someone needs stateful proxies, I'd like to understand what the problem
> stateful proxies are trying to solve is, and why the current solution
> is insufficient.  Wit respect to the App ID = 0 issue, we assumed that
> proxies are stateless.
> 
> John
> >-----Original Message-----
> >From: ext Tony Zhang [mailto:[email-masked]] 
> >Sent: 24 July, 2006 02:00
> >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
> >Cc: [email-masked]
> >Subject: Re: [Dime] Summary of 3588bis Issues Status
> >
> >Hi Marco:
> >
> >    I also agree the generic problem of "How can a proxy stay 
> >>on the path during a session", but i think this problem is 
> >address the stateful proxy agent,acutal maybe still have 
> >stateless proxy agent.so the routing problem still in here.
> >    I still think the routing is common part,independent on 
> >start ,end ,interim session message.
> >
> >Regards
> >Tony
> >----- Original Message -----
> >From: "STURA, Marco, VF-IT" <[email-masked]>
> >To: "Tony Zhang" <[email-masked]>; "Tolga Asveren" 
> ><[email-masked]>; "Victor Fajardo" <[email-masked]>
> >Cc: <[email-masked]>
> >Sent: Friday, July 21, 2006 3:18 PM
> >Subject: RE: [Dime] Summary of 3588bis Issues Status
> >
> >
> >Hi Tony,
> >
> >Server initiated requests can only be sent in the context of 
> >existing sessions and routing must be done on the basis of 
> >Destination-Host to ensure that the request hits the correct 
> >client, so app id is not enough.
> >
> >The routing problem you are discussing has to do with how a 
> >proxy can stay on the path during a session so that a server 
> >can send a request, say ASR or RAR, to Destination-Host via P1 
> >to C1. As also suggested by Tolga
> >
> >>I think it can be deducted to the generic problem of "How can 
> >a proxy stay >on the path during a session", so I believe this 
> >is the question to answer >(which we already discussed to some 
> >extent in the context of strict-routing >draft review)
> >
> >So I think your issue can be discussed in that context, app id 
> >0 for common messages I think is fine.
> >
> >Regards
> >Marco
> >
> >-----Original Message-----
> >From: Tony Zhang [mailto:[email-masked]] 
> >Sent: venerdì 21 luglio 2006 5.43
> >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
> >Cc: [email-masked]
> >Subject: Re: [Dime] Summary of 3588bis Issues Status
> >
> >Hi Macro:
> >
> >[MSt] I think you assume P1 and P2 advertise supports for App 
> >x/y and App z respectively but I would rather consider this 
> >configuration an academic use case since typically you have 
> >only one logical Proxy as a interconnect point for a given 
> >realm in real deployments as a central point for policy 
> >enforcement. However, let see whether a server initiated 
> >message using Destination-Host and app id 0 based routing works.
> >
> >S1 sends ASR to C3 (C3 diameter identity in Destination-Host 
> >AVP) app id 0. In the realm-based routing table R1 will 
> >certainly find a match for realm A and app id 0, say for 
> >instance the match is for P1. ASR is routed to P1, which 
> >doesn't have C3 in its peer table and then answers with 
> >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the 
> >message via the alternative entry for Realm A, hence P2. P2 
> >now deliver the message to C3. So, app-id 0 works at the end 
> >if Destination-Host based routing is used and, actually, is to 
> >be used for certain server initiated messages as also defined 
> >in RFC 3588 in section 6.1. 
> >
> >[Tony]Because the Application Id 0,not advertisement in 
> >CER/CEA,so it means each realm will use the peet table select 
> >next hop,almost peer table have many peer can select,also 
> >include peer of receive the request. so it can happen loop 
> >routing.(maybe can add one process avoid this,when routing 
> >should input peer name of receive the request.).the other 
> >problem,after retry many peer ,then we find correct route,it 
> >consume long time,maybe the client already timer expire.also 
> >application id use for effectively routing,but for above the 
> >case ,it is not like this.
> >
> >sorry about i discuss this again,after 2004's dicuss,it is 
> >likely many people confusion.if this time have same conlusion 
> >maybe still have same problem.
> >
> >Thanks!
> >Tony
> >
> >----- Original Message ----- 
> >From: "STURA, Marco, VF-IT" <[email-masked]>
> >To: "Tolga Asveren" <[email-masked]>; "Victor Fajardo" 
> ><[email-masked]>
> >Cc: <[email-masked]>
> >Sent: Wednesday, July 19, 2006 5:11 PM
> >Subject: RE: [Dime] Summary of 3588bis Issues Status
> >
> >
> >See in line.
> >
> >Regards
> >Marco
> >
> >-----Original Message-----
> >From: Tolga Asveren [mailto:[email-masked]] 
> >Sent: martedì 18 luglio 2006 18.52
> >To: STURA, Marco, VF-IT; Victor Fajardo
> >Cc: [email-masked]
> >Subject: RE: [Dime] Summary of 3588bis Issues Status
> >
> >[.. snip ..]
> >> I agree with your example above regarding destination-host. It is
> >> required in the case of ASR (and perhaps some other message) though I
> >> guess I was stating a case which is a little bit different than your
> >> example above. I was thinking of the following case:
> >>
> >> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server
> >>
> >> in this case relay2 will not be able to route using 
> >dest-host. This is
> >> where dest-realm and app id becomes important. In this case 
> >app id of 0
> >> might not work as well ... or maybe I'm wrong.
> >>
> >> [MSt] In this case R1 would advertise it self as a relay (i.e.
> >> 0xffffffff) it won't advertise app id x or y or z. So, any app id
> >> would be routed to R1 by R2.
> >[TOLGA] Let me try to further refine the scenario:
> >              *****************************
> >              *  Realm A                  *
> >              *                           *
> >              *           +---------+     *
> >              *        +--+C1 App=X |     *
> >              * +----+ |  +---------+     *
> >         +----*-+ P1 +-+  +---------+     *
> >+---+  +-+--+ * +----+----+C2 App=Y |     *
> >|S1 +--+ R1 | *           +---------+     *
> >+---+  +-+--+ *                           *
> >         |    * +----+                    *
> >         +----*-+ P2 +----+---------+     *
> >              * +----+    |C3 App=Z |     *
> >              *           +---------+     *
> >              *                           *
> >              *****************************
> >In this case, R1 wouldn't have enough knowledge to route the message
> >properly to the correct proxy just by looking to the App-Id in 
> >the message
> >header, if App-Id is populated with "0".
> >
> >[MSt] I think you assume P1 and P2 advertise supports for App 
> >x/y and App z respectively but I would rather consider this 
> >configuration an academic use case since typically you have 
> >only one logical Proxy as a interconnect point for a given 
> >realm in real deployments as a central point for policy 
> >enforcement. However, let see whether a server initiated 
> >message using Destination-Host and app id 0 based routing works.
> >
> >S1 sends ASR to C3 (C3 diameter identity in Destination-Host 
> >AVP) app id 0. In the realm-based routing table R1 will 
> >certainly find a match for realm A and app id 0, say for 
> >instance the match is for P1. ASR is routed to P1, which 
> >doesn't have C3 in its peer table and then answers with 
> >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the 
> >message via the alternative entry for Realm A, hence P2. P2 
> >now deliver the message to C3. So, app-id 0 works at the end 
> >if Destination-Host based routing is used and, actually, is to 
> >be used for certain server initiated messages as also defined 
> >in RFC 3588 in section 6.1. 
> >
> >
> >_______________________________________________
> >DiME mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 
> 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 4 Aug 2006 11:50:30 -0400

Please see comments for below.

   thanks,
   tolga

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Friday, August 04, 2006 11:32 AM
> To: Tony Zhang
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
[TOLGA]Although there may be cases where strict-routing may be useful (an
issue for another thread), this shouldn't be an argument in favor of AppId=0
IMHO. There are a variety of very real-life and useful configurations, which
work with AppId!=0 fine just following the routing procedures defined in
RFC3588, e.g. a load-balancer in front of backend servers for a specific
application, such a node advertises support only for a specific application,
or a policy enforcer again for a specific application. The point is, once an
intermediarey node wants to do something for a specific
application -regardless of whether it keeps state or not-, appId=0  creates
problems.

That being said, I understand the issue  about backward-compatibility, just
let's be aware that there are certain technical drawbacks associated with
AppId=0.
> > To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > Cc: [email-masked]
> > >Sent: venerd?_ 21 luglio 2006 5.43
> > >Sent: marted?_ 18 luglio 2006 18.52

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 04 Aug 2006 13:32:52 -0400

On Fri, Aug 04, 2006 at 11:50:30AM -0400, Tolga Asveren wrote:

(snip)

> let's be aware that there are certain technical drawbacks associated with

I agree.  I guess we are in agreement that maintaining backward
compability is more important than optimization like load-balancing.

Yoshihiro Ohba