Re: [Dime] Questions regarding RFC 6733

[Ajinkya Joshi <[e-mail]>]

Hi Lionel,

I completely agree with you, if it is just one transport connection from
the external world perspective, then it doesn't really matter even if there
are multiple processes (instances) within that peer handling that one
transport. But I feel that RFC wording doesn't really indicate that.
(section 2.1)
"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"

This can get interpreted as multiple transport connections are allowed
using same diameteridentity.

On Wed, Mar 8, 2017 at 4:39 PM, <[e-mail]> wrote:

> Hi Ajinkya,
>
>
>
> This will depend on how your "fork" is implemented and it is why it is
> considered as "implementation-specific".
>
> If N instances are sharing the same Diameter id (DiamId 1), you may have a
> way to consider the connection up as long as one instance inside the peer
> is available and active. In that case, there is no impact for other
> diameter peers in the network. For the outside world, there would be only
> one transport connection opened with "DiamId 1", independently of the
> number of instance behind "DiamId 1".
>
>
>
> Lionel
>
>
>
> *De :* DiME [mailto:[e-mail]] *De la part de* Ajinkya Joshi
> *Envoyé :* mercredi 8 mars 2017 10:37
> *À :* jouni.nospam
> *Cc :* [e-mail]
> *Objet :* Re: [Dime] Questions regarding RFC 6733
>
>
>
>
>
>
>
> On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam <[e-mail]>
> wrote:
>
> hi,
>
> > On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi <[e-mail]>
> 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.
>
>
>
> [ajoshi] If we fork a new peer instance with same diameteridentity, won't
> it create problems as per peer state machine? Because, you would have
> separate transport connection for each of them and each transport
> connection needs capability exchange and as per peer state machine, there
> can be only one capability exchange. I am inferring this based on section
> 5.3 which says "When two Diameter peers establish a transport connection,
> they MUST exchange the Capabilities Exchange messages". Am I missing
> something here? Or is it the case that two peers (identified based on their
> respective diameter host-names) would perform capability exchange only
> once, irrespective of number of transport connections they have?
>
>
>
>
> >       • 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dime
>
>
>
>
>
> --
>
> Regards,
>
> Ajinkya Joshi
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>


-- 
Regards,
Ajinkya Joshi