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

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

> -----Message d'origine-----
> De : Dave Dolson [mailto:ddolson@sandvine.com]
> Envoyé : mardi 8 mars 2016 16:40
> À : MORAND Lionel IMT/OLN; Jouni Korhonen; dime@ietf.org
> 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?
> 
> It seems like it may use the same one without harm.
> 
> -Dave
> 
> 
> 
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of
> lionel.morand@orange.com
> Sent: Tuesday, March 08, 2016 10:01 AM
> To: Jouni Korhonen; dime@ietf.org
> Subject: Re: [Dime] Diameter retransmission -- to use same hop-by-hop and
> end-to-end IDs?
> 
> Hi David,
> 
> I agree with Jouni.
> See below for more details.
> 
> BR,
> 
> Lionel
> 
> > -----Message d'origine-----
> > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> > Envoyé : vendredi 4 mars 2016 23:56 À : dime@ietf.org Objet : Re:
> > [Dime] Diameter retransmission -- to use same hop-by-hop and
> > end-to-end IDs?
> >
> > 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
> > >
> > > 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?
> >
> > 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..
> 
> [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."
> > 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.
> 
> > > 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?
> >
> > See above.
> >
> [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
> > >
> > > Senior Software Architect, Sandvine Inc.
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

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.