Subject: [Dime] Questions regarding RFC 6733

From: Ajinkya Joshi <[email-masked]>
Date: Tue, 7 Mar 2017 16:31:17 +0530

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
   - 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)

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 ?

-- 
Regards,
Ajinkya Joshi

---

From: "jouni.nospam" <[email-masked]>
Date: Tue, 7 Mar 2017 08:34:34 -0800

hi,

> On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi <[email-masked]> wrote:
> 
> Hello,
> 
> I have following questions regarding diameter RFC 6733, I would really appreciate if someone can help me with these.
> 
>     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.

>       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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Yuval Lifshitz <[email-masked]>
Date: Wed, 8 Mar 2017 07:19:06 +0000

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:[email-masked]] On Behalf Of jouni.nospam
Sent: Tuesday, March 07, 2017 6:35 PM
To: Ajinkya Joshi
Cc: [email-masked]
Subject: Re: [Dime] Questions regarding RFC 6733

hi,

- jouni

---

From: Ajinkya Joshi <[email-masked]>
Date: Wed, 8 Mar 2017 15:06:54 +0530

On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam <[email-masked]>
wrote:

> >     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
> >       • 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.
>
>
> >       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 ?
>

-- 
Regards,
Ajinkya Joshi

---

From: <[email-masked]>
Date: Wed, 8 Mar 2017 11:01:01 +0000

Hi Yuval,

Per connection, you will be able to test the liveness of the connection (SCTP, DW, etc.). If something is wrong, you will be able to detect it and tear down the connection.
And then accept the new CER if received.

Regards,

Lionel

> -----Message d'origine-----
> De : DiME [mailto:[email-masked]] De la part de Yuval Lifshitz
> Envoyé : mercredi 8 mars 2017 08:19
> À : jouni.nospam; Ajinkya Joshi
> Cc : [email-masked]
> Objet : 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.
> 
> >     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
> 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
> 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.
> 
> 
> 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
> connection again? Or DNS lookup is driven only by TTL field received in the prior
> DNS answer ?
> 

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Wed, 8 Mar 2017 11:09:05 +0000

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:[email-masked]] De la part de Ajinkya Joshi
Envoyé : mercredi 8 mars 2017 10:37
À : jouni.nospam
Cc : [email-masked]
Objet : Re: [Dime] Questions regarding RFC 6733

On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam <[email-masked]<mailto:[email-masked]>> wrote:
hi,

> On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hello,
>

[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?

- jouni

> [email-masked]<mailto:[email-masked]>

--
Regards,
Ajinkya Joshi

---

From: Ajinkya Joshi <[email-masked]>
Date: Wed, 8 Mar 2017 19:03:33 +0530

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, <[email-masked]> wrote:

> 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:[email-masked]] *De la part de* Ajinkya Joshi
> *Envoyé :* mercredi 8 mars 2017 10:37
> *À :* jouni.nospam
> *Cc :* [email-masked]
> *Objet :* Re: [Dime] Questions regarding RFC 6733
>
>
>
>
>
>
>

-- 
Regards,
Ajinkya Joshi

---

From: <[email-masked]>
Date: Wed, 8 Mar 2017 14:38:39 +0000

Hi,

This text may not be the most self-explicit ☺
The intention was to clarify that multiple Diameter instances could be on the same host.
It is maybe more accurately described below:

   DiameterIdentity

      The DiameterIdentity format is derived from the OctetString Basic
      AVP Format.

                        DiameterIdentity  = FQDN/Realm

   The DiameterIdentity value is used to uniquely identify either:

      *  A Diameter node for purposes of duplicate connection and
         routing loop detection.

      *  A Realm to determine whether messages can be satisfied locally
         or whether they must be routed or redirected.

      When a DiameterIdentity value is used to identify a Diameter node,
      the contents of the string MUST be the Fully Qualified Domain Name
      (FQDN) of the Diameter node.  If multiple Diameter nodes run on
      the same host, each Diameter node MUST be assigned a unique
      DiameterIdentity.  If a Diameter node can be identified by several
      FQDNs, a single FQDN should be picked at startup and used as the
      only DiameterIdentity for that node, whatever the connection on
      which it is sent.  In this document, note that DiameterIdentity is
      in ASCII form in order to be compatible with existing DNS
      infrastructure.  See Appendix D<https://tools.ietf.org/html/rfc6733#appendix-D> for interactions between the
      Diameter protocol and Internationalized Domain Names (IDNs).

If you have multiple instances on the same host, each one will have its own Diameter Id and each Diameter Id can use a single connection, which means N connections for the host.
Everything else than the "1 connection per Diameter Id" paradigm is out of the Diameter spec. Same for how could implemented the "1 Diameter Id" in an multiple instance environment, as pointed out by Jouni.

In the peer state machine description, it is clear that only one connection is created per Diameter Id, i.e. one TCP connection or one SCTP association (which can be multi-homed). And it is based on this principle that CER/CEA and DWR/DWA are used.
Now, it is also said:

   The state machine constrains only the behavior of a Diameter
   implementation as seen by Diameter peers through events on the wire.

   Any implementation that produces equivalent results is considered
   compliant.

So whatever the implementation of the Diameter node, e.g. 1 or N instance on the same host, 1 or N Diameter Ids, this node should comply with requirements regarding the connection management.

Regards,

Lionel

De : Ajinkya Joshi [mailto:[email-masked]]
Envoyé : mercredi 8 mars 2017 14:34
À : MORAND Lionel IMT/OLN
Cc : jouni.nospam; [email-masked]
Objet : Re: [Dime] Questions regarding RFC 6733

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, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ajinkya,

Lionel

De : DiME [mailto:[email-masked]<mailto:[email-masked]>] De la part de Ajinkya Joshi
Envoyé : mercredi 8 mars 2017 10:37
À : jouni.nospam
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] Questions regarding RFC 6733

- jouni

--
Regards,
Ajinkya Joshi

Thank you.

--
Regards,
Ajinkya Joshi

---

From: jouni korhonen <[email-masked]>
Date: Wed, 8 Mar 2017 14:00:05 -0800

Hi,

I specifically said that you would need to instantiate new peer state
machines.. otherwise it does not really work.

- Jouni

On Wed, Mar 8, 2017 at 1:36 AM, Ajinkya Joshi <[email-masked]

>> >     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).
>> >