Re: [Dime] Questions regarding RFC 6733

Regarding (1), another possible implementation would be that upon receiving a new connection from the same host, you would tear down the existing connection and allow the new one. This would be useful in the case that a client became deadlocked or didn't shutdown properly, and a new client tries to take over and continue the work of the stalled ones.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of jouni.nospam
Sent: Tuesday, March 07, 2017 6:35 PM
To: Ajinkya Joshi
Cc: dime@ietf.org
Subject: Re: [Dime] Questions regarding RFC 6733

hi,

> On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi <ajoshi@definitionnetworks.com> wrote:
> 
> Hello,
> 
> I have following questions regarding diameter RFC 6733, I would really appreciate if someone can help me with these.
> 
> 1. Regarding diameter peer state machine -
>     
>     Section 5.6.1 (Peer State Machine --> Incoming connections) mentions that Origin-host is used for     identifying peer state machine and as per state machine, once it moves into I-Open, new CER is       rejected. This concludes, that there can't be more than one transport connections with same               diameter host (as specified by Origin-host). 
> 
>     Section 2.1 (Transport) mentions that "A given Diameter instance of the peer state machine MUST      NOT use more than one transport connection to communicate with a given peer, unless multiple        instances exist on the peer, in which, case a separate connection per process is allowed."
> 
>      Questions -- 
> 	• Does section 2.1 implicitly assumes that multiple diameter instances (within a peer) would correspond to different diameter host ? Otherwise, it could contradict with section 5.6.1

it assumes one peer connection per peer state machine. so if you have a way to ‘fork’ a new peer instance with its own peer state machine per incoming connection then having “multiple instances’ is possible even if the diameteridentity is the same. 

> 	• If multiple transport connections (towards the same peer) are allowed per diameter host, is it expected that peer would do load balancing between them? (There is a connection load balancing section in RFC 3539 - Section 3.4.3)

what you do and how you manage ‘multiple instances’ if more or less left for implementation to decide. i always considered it as a node internal compute load balancing mechanism i.e., to distribute the compute to separate cores/blades etc.

> 2. Regarding diameter peer failback procedure -
> 
>       Section 5.5.4 mentions "a connection request should be periodically attempted with the failed              peer in order to re-establish the transport connection"  
> 
>       Question -- 
> 
> 	• If the failed peer is dynamically discovered via DNS lookup, is it expected that peer would perform DNS query before trying to establish the connection again? Or DNS lookup is driven only by TTL field received in the prior DNS answer ?

up to your implementation and dns resolver implementation. 

- jouni

> -- 
> Regards,
> Ajinkya Joshi
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime