Subject: [Dime] Diameter failover

From: "Venu K" <[email-masked]>
Date: Tue, 3 Jun 2008 21:08:24 +0530

Hi ,

If a response is received by a diameter node for Diameter client A(from
where request had originated) , can the response be forwarded to client B
in cases where client A is not reachable/down.
Assuming Client B knows about session and hostidentifiers of client A.

Regards,
Venu
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: a21917 <[email-masked]>
Date: Wed, 04 Jun 2008 17:56:49 +0530

Hi Venu

This scenario is identical to the scenario wherein there has been a 
connection re-establishment between the client and server before the 
answer is sent back by the server. If the host name and domain name of 
the secondary client are same as that of the primary's then you can 
seamlessly send the answer message to the secondary.

Regards,
Liyaqatali G Nadaf

Venu K wrote:
> Hi ,
>
> If a response is received by a diameter node for Diameter client 
> A(from where request had originated) , can the response be forwarded 
> to client B  in cases where client A is not reachable/down.
> ------------------------------------------------------------------------
>

---

From: "Venu K" <[email-masked]>
Date: Wed, 4 Jun 2008 19:22:59 +0530

Thank you, Is there any way we could possibly send it to a client with
different hostname ?

Regards,
Venu

On Wed, Jun 4, 2008 at 5:56 PM, a21917 <[email-masked]> wrote:

> connection re-establishment between the client and server before the answer
> is sent back by the server. If the host name and domain name of the
> secondary client are same as that of the primary's then you can seamlessly
> send the answer message to the secondary.
>
> Regards,
> Liyaqatali G Nadaf
>
> Venu K wrote:
>
> Hi ,
>
> ------------------------------
>
> DiME mailing [email-masked]://www.ietf.org/mailman/listinfo/dime
>
>

-- 
Regards,
Venu(http://venugrk.blogspot.com/)
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 4 Jun 2008 13:52:22 -0400

I think not trying to send the answer to the client is a better option in this case:

a) If client went down, standby client would resend the request.
b) If connection went down, client would either try to send the request via another next-hop or would resend it after connection reestablishment 

I would classify "retransmissions" in b) in two different categories. The first one is on base protocol level. For the second one, I would expect base protocol to inform the application that it failed to send the request (assuming there are no alternate next-hops) and the application trying to send a new message, i.e. a request which is a new one from base protocol perspective.

Sending back the answer to an alternate client may require some smarts on the client side:
a) It would require the standby-client to recognize the answer as a valid one (corresponding request was not sent by it)
b) It would require the client to be ready to handle two answers for the same request for the connection reestablishment. 

Thanks,
Tolga

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Venu K
Sent: Wednesday, June 04, 2008 9:53 AM
To: a21917
Cc: [email-masked]
Subject: Re: [Dime] Diameter failover

Thank you, Is there any way we could possibly send it to a client with different hostname ?

Regards,
Venu

This scenario is identical to the scenario wherein there has been a connection re-establishment between the client and server before the answer is sent back by the server. If the host name and domain name of the secondary client are same as that of the primary's then you can seamlessly send the answer message to the secondary.

Regards,
Liyaqatali G Nadaf

Venu K wrote: 
Hi ,

If a response is received by a diameter node for Diameter client A(from where request had originated) , can the response be forwarded to client B  in cases where client A is not reachable/down.
Assuming Client B knows about session and hostidentifiers of client A.

Regards,
Venu
________________________________________

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Jun 2008 21:45:12 +0300

I believe that the entire scenario does not seem to be right. Venu, 
could you motivate it a bit more?

Ciao
Hannes

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Jun 2008 08:59:04 +0700

Liyaqatali G Nadaf [mailto://[email-masked]] writes:

Hi Venu

[gwz] What an interesting idea!  I wonder how the DNS will function in the
face of two or more hosts w/the same FQDN...

...

---

From: Ralph Loader <[email-masked]>
Date: Thu, 5 Jun 2008 14:18:24 +1200

> If the host name and domain name
> of the secondary client are same as that of the primary's then you
> can seamlessly send the answer message to the secondary.

I don't see how this can work.

How is the request/answer matching meant to work if an answer is sent
on a connection that the request was not sent on?

The hop-by-hop id is only guarenteed unique per-connection, and the
end-end id might not unique across client re-boots.

So unless the server knows that the clients provide uniqueness
guarentees beyond those required by the protocol, an answer sent on a
different connection than the request is potentially ambiguous.

Ralph.

> 
> [gwz] What an interesting idea!  I wonder how the DNS will function
> in the face of two or more hosts w/the same FQDN...
> 
> ...
> 
>

---

From: "Venu K" <[email-masked]>
Date: Fri, 6 Jun 2008 20:56:32 +0530

Thank You all, The requirement is because when AS(application server) in a
cluster fails , another AS node picks up requests served by the
server that is out of service. The diameter messages to be sent to the out
of service AS needs to be forwarded to AS node which has picked
up the requests.

Regards
Venu

On Thu, Jun 5, 2008 at 7:45 AM, Ralph Loader <[email-masked]>
wrote:

> > answer is sent back by the server. If the host name and domain name
> end-end id might not unique across client re-boots (or over different
> clients).
>
> guarentees beyond those required by the protocol, sending an answer
> on a different connection than the request is potentially ambiguous as
> to what request it matches.
>
> Ralph.
>
> >
> > Regards,
> > Liyaqatali G Nadaf
> >
> > Venu K wrote:
> > > Hi ,
> > >
> > > A(from where request had originated) , can the response be
> > > forwarded to client B  in cases where client A is not
> > > reachable/down. Assuming Client B knows about session and
> > > hostidentifiers of client A.
> > >
> > > Regards,
> > > Venu
> > >

---

From: "Venu K" <[email-masked]>
Date: Sun, 8 Jun 2008 11:50:00 +0530

Right , w.r.t my original question in this thread are we allowed (as per
spec) to forward Diameter reply messages of out of service AS node
to AS node which is taken over.

+++

6.2.2 from RFC 3588

 The agent MUST then send the answer to the host that it received the
   original request from.

Regards,
Venu

On Sat, Jun 7, 2008 at 11:03 PM, Himanshu Rawat <[email-masked]>
wrote:

> Hi Venu,
>
> The scenario that you've described is possible and generally covered under
> high availability i.e. HA. Usually the AS should be available 99.999 % for
> the service, and if any of the server or node goes down then immediately
> other AS should start processing the request.
>
> The required information to build the request is stored in the common
> storage(it can be hardisk or database or any other thing), the other server
> should know how to process the request (means in which state were they when
> node got down) which were served by the node that got down. This is one of
> the ways where other server can start processing the request.
>
> Please revert if it's not clear.
>
> Himanshu
>
>
> On Fri, Jun 6, 2008 at 8:56 PM, Venu K <[email-masked]> wrote:
>
>> On Thu, Jun 5, 2008 at 7:45 AM, Ralph Loader <
>> [email-masked]> wrote:
>>
>>>

---

From: <[email-masked]>
Date: Mon, 9 Jun 2008 09:03:44 +0300

Hi,

> Right , w.r.t my original question in this thread are we 
> allowed (as per spec) to forward Diameter reply messages of 
> out of service AS node to AS node which is taken over.

No, you are not allowed to do that according to RFC 3588.

If you design and deploy an HA solution that behaves this way
you should take into account that "standard" Diameter clients
and servers do not support it.

Best Regards,
Mikko Aittola

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Venu K
>Sent: 08 June, 2008 09:20
>To: Himanshu Rawat
>Cc: [email-masked]
>Right , w.r.t my original question in this thread are we 
>allowed (as per spec) to forward Diameter reply messages of 
>out of service AS node
>On Sat, Jun 7, 2008 at 11:03 PM, Himanshu Rawat 
><[email-masked]> wrote:
>
>
>	Hi Venu,
>	
>	The scenario that you've described is possible and 
>generally covered under high availability i.e. HA. Usually the 
>AS should be available 99.999 % for the service, and if any of 
>the server or node goes down then immediately other AS should 
>start processing the request.
>	
>	The required information to build the request is stored 
>in the common storage(it can be hardisk or database or any 
>other thing), the other server should know how to process the 
>request (means in which state were they when node got down) 
>which were served by the node that got down. This is one of 
>		Thank You all, The requirement is because when 
>AS(application server) in a cluster fails , another AS node 
>picks up requests served by the
>		server that is out of service. The diameter 
>messages to be sent to the out of service AS needs to be 
>forwarded to AS node which has picked
>		up the requests.
>		
>		
>		
>		Regards
>		Venu