Subject: [Dime] Diameter retransmission -- to use same hop-by-hop and end-to-end IDs?

From: Dave Dolson <[email-masked]>
Date: Fri, 4 Mar 2016 15:55:10 +0000

Hello Diameter experts,

We've been looking to the specs in order to answer the question as to whether a
retransmitted Diameter request MUST/SHOULD/SHOULD NOT/MAY use the same
hop-by-hop and end-to-end identifiers as the original request.

Can anyone point to the position of the standards, or ad hoc standards in this regard?

A secondary question is whether an agent MUST/SHOULD/SHOULD NOT/MAY
use the same hop-by-hop identifier when forwarding a retransmitted request that it used the
first time the message was seen.
My sense is that an agent is not required to do so, but may it do so?

Thanks in advance,

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 4 Mar 2016 14:56:20 -0800

Hi,

On top of my head.. and in a tired condition :)

3/4/2016, 7:55 AM, Dave Dolson kirjoitti:
> Hello Diameter experts,
>
> We’ve been looking to the specs in order to answer the question as to
> whether a
>

RFC6733 Section 3 says "The sender MUST ensure that the Hop-by-Hop 
Identifier in a request is unique on a given connection at any given 
time". So if a different transport connection is used as a result of 
retransmission, the h-b-h id could potentially be different than in the 
original request. If different h-b-h ids were used over the same 
connection for the same buffered request messages that should also 
work.. I do not recall any text specifically prohibiting that. Not that 
I would find this kind of behaviour good, either..

RFC6733 Section 3 says "The End-to-End Identifier MUST NOT be modified 
by Diameter agents of any kind." Also "Duplicate requests SHOULD cause 
the same answer to be transmitted (modulo the Hop-by-Hop Identifier 
field and any routing AVPs that may be present), and they MUST NOT 
affect any state that was set when the original request was processed." 
And Section 5.5.4. says "The End-to-End Identifier field in the Diameter 
header along with the Origin-Host AVP MUST be used to identify duplicate 
messages."

The combination of Origin-Host and e-t-e id must be unique for duplicate 
detection. Now if either one changes the receiver potentially has issues 
determining correctly to which previously seen message the request was a 
retransmission for.

> My sense is that an agent is not required to do so, but may it do so?

See above.

- JOuni

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

---

From: <[email-masked]>
Date: Tue, 8 Mar 2016 15:00:39 +0000

Hi David,

I agree with Jouni.
See below for more details.

BR,

Lionel

> -----Message d'origine-----
> De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
> Envoyé : vendredi 4 mars 2016 23:56
> À : [email-masked]
> Objet : Re: [Dime] Diameter retransmission -- to use same hop-by-hop and
> end-to-end IDs?
> 
> Hi,
> 
> Identifier in a request is unique on a given connection at any given time". So
> if a different transport connection is used as a result of retransmission, the h-
> b-h id could potentially be different than in the original request. If different
> h-b-h ids were used over the same connection for the same buffered
> request messages that should also work.. I do not recall any text specifically
> prohibiting that. Not that I would find this kind of behaviour good, either..

[LM] The HBH id is rather manage at the Diameter node level than at the connection level. In several places, it is said "locally unique value" without reference to any connection. More specifically, in the relay/proxy case, it is even said "The Hop-by-Hop Identifier in the request is saved and replaced with a  locally unique value.  The source of the request is also saved, which includes the IP address, port, and protocol." which must be interpreted as that only the HBH Id is required to match received answers and information about source of the request is only used for forwarding the answer to the request originator. And this is confirmed by "A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an answer received against the list of pending requests." where the notion of HBH id per connection would not make sense. 
Anyway, in any case the HBH Id in the duplicate request is different from the HBH id of the original request.  Any request must have unique HBH Id as specified in "The Hop-by-Hop Identifier SHOULD be set to a locally unique value" in the section 6.1.2. "Sending a request", that is valid for any request (original or retransmitted).

> 
> RFC6733 Section 3 says "The End-to-End Identifier MUST NOT be modified by
> Diameter agents of any kind." Also "Duplicate requests SHOULD cause the
> same answer to be transmitted (modulo the Hop-by-Hop Identifier field and
> any routing AVPs that may be present), and they MUST NOT affect any state
> that was set when the original request was processed."
[LM] if either one is change, it is a new request from a Diameter base protocol point of view. There is no way for the server to detect that the request is a retransmitted request, even if the T flag is set in the request. It will not be able to match the retransmitted request to the original one.

> > My sense is that an agent is not required to do so, but may it do so?
[LM] When a request is retransmitted by a proxy/relay, the agent is the "originator" of the retransmitted request. The principle given in section 6.1.2 applies here also. The HBH Id in a retransmitted request will be different from the one in the request initially forwarded.

> > Senior Software Architect, Sandvine Inc.

_________________________________________________________________________________________________________________________

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: Dave Dolson <[email-masked]>
Date: Tue, 8 Mar 2016 15:39:34 +0000

Thanks Jouni and Lionel.

I understand the argument that a receiver may see a different hop-by-hop ID on a retransmitted message, especially if it took a different path to arrive.

But I'm still unclear on whether the originator of a retransmitted request MUST use a different hop-by-hop ID or whether it MAY use the same one?

It seems like it may use the same one without harm.

-Dave

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 08, 2016 10:01 AM
To: Jouni Korhonen; [email-masked]
Subject: Re: [Dime] Diameter retransmission -- to use same hop-by-hop and end-to-end IDs?

Hi David,

I agree with Jouni.

BR,

Lionel

---

From: <[email-masked]>
Date: Wed, 9 Mar 2016 09:13:01 +0000

Hi David,

I think I got your point.

There is the following text in RFC6733:

  " It is important to note that multiple identical requests or answers
   MAY be received as a result of a failover.  The End-to-End Identifier
   field in the Diameter header along with the Origin-Host AVP MUST be
   used to identify duplicate messages."

If there are identical, this includes the hop-by-hop Id.

I think it covers your point as follow:

A copy of the original request is stored in the list of pending requests.

  " o  The message SHOULD be saved in the list of pending requests."
   
  " However, the protocol's failover procedures
   require that agents maintain a copy of pending requests."

In failure case:
   
  " Typically, all
   messages for a realm are sent to the primary peer but, in the event
   that failover procedures are invoked, any pending requests are sent
   to the secondary peer."

  " In the event that a transport failure is detected with a peer, it is
   necessary for all pending request messages to be forwarded to an
   alternate agent, if possible.  This is commonly referred to as
   "failover"."

It can be assumed that, if the request was saved in the pending request list, a "copy" of the original request is forwarded to an alternate peer if no answer has been received for the first request.
In that case, the retransmitted request is identical to the original request, including the HBH Id.

It is up to the sender to maintain consistency in the handling of the pending request list and the HBH Id.

Could you explain what is your original issue? Any interoperability problem?

Regards,

Lionel

> De : Dave Dolson [mailto:[email-masked]]
> Envoyé : mardi 8 mars 2016 16:40
> À : MORAND Lionel IMT/OLN; Jouni Korhonen; [email-masked]
> Objet : RE: [Dime] Diameter retransmission -- to use same hop-by-hop and
> end-to-end IDs?
> 
> Thanks Jouni and Lionel.
> 
> I understand the argument that a receiver may see a different hop-by-hop ID
> on a retransmitted message, especially if it took a different path to arrive.
> 
> But I'm still unclear on whether the originator of a retransmitted request
> MUST use a different hop-by-hop ID or whether it MAY use the same one?
> 
> > Envoyé : vendredi 4 mars 2016 23:56 À : [email-masked] Objet : Re:
> > [Dime] Diameter retransmission -- to use same hop-by-hop and
> > end-to-end IDs?
> >
> > Hi,
> >
> > retransmission, the h- b-h id could potentially be different than in
> > the original request. If different h-b-h ids were used over the same
> > work.. I do not recall any text specifically prohibiting that. Not that I would
> find this kind of behaviour good, either..
> 
> [LM] The HBH id is rather manage at the Diameter node level than at the
> connection level. In several places, it is said "locally unique value" without
> reference to any connection. More specifically, in the relay/proxy case, it is
> even said "The Hop-by-Hop Identifier in the request is saved and replaced
> with a  locally unique value.  The source of the request is also saved, which
> includes the IP address, port, and protocol." which must be interpreted as
> that only the HBH Id is required to match received answers and information
> about source of the request is only used for forwarding the answer to the
> request originator. And this is confirmed by "A Diameter client or proxy
> MUST match the Hop-by-Hop Identifier in an answer received against the list
> of pending requests." where the notion of HBH id per connection would not
> make sense.
> Anyway, in any case the HBH Id in the duplicate request is different from the
> HBH id of the original request.  Any request must have unique HBH Id as
> specified in "The Hop-by-Hop Identifier SHOULD be set to a locally unique
> value" in the section 6.1.2. "Sending a request", that is valid for any request
> (original or retransmitted).
> 
> >
> > And Section 5.5.4. says "The End-to-End Identifier field in the
> > Diameter header along with the Origin-Host AVP MUST be used to
> > identify duplicate messages."
> >
> > The combination of Origin-Host and e-t-e id must be unique for
> > duplicate detection. Now if either one changes the receiver
> > potentially has issues determining correctly to which previously seen
> > message the request was a retransmission for.
> >
> [LM] if either one is change, it is a new request from a Diameter base
> protocol point of view. There is no way for the server to detect that the
> request is a retransmitted request, even if the T flag is set in the request. It
> will not be able to match the retransmitted request to the original one.
> 
> [LM] When a request is retransmitted by a proxy/relay, the agent is the
> "originator" of the retransmitted request. The principle given in section 6.1.2
> applies here also. The HBH Id in a retransmitted request will be different
> from the one in the request initially forwarded.
> 
> > - JOuni
> >
> > >
> > > Thanks in advance,
> > >
> > > David Dolson
> > >
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.