Subject: [Dime] Re: DiME Digest, Vol 13, Issue 10

From: "Monal Sengar" <[email-masked]>
Date: Wed, 17 Jan 2007 00:08:01 +0530

Hi,

I agree with Rajith as as per section Section 7 (page 83) " The Result-Code
AVP describes the error that the Diameter node  encountered in its
processing.  In case there are multiple errors, the Diameter node MUST
report only the first error it encountered."

 So there shouldnt be the case when we need to report multiple Failed AVP.

Regards

Monal

On 1/16/07, [email-masked] <[email-masked]> wrote:
>
> Send DiME mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www1.ietf.org/mailman/listinfo/dime
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DiME digest..."
>
>
> Today's Topics:
>
>    1. RE: Result code of Multiple failed Avps (Rajith R)
>    2. RE: Result code of Multiple failed Avps (Nimish Bhargava)
>    3. RE: The Auditing Problem (Ulf Bodin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 16 Jan 2007 11:30:55 +0530
> From: Rajith R <[email-masked]>
> Subject: RE: [Dime] Result code of Multiple failed Avps
> To: "'Glen Zorn (gwz)'" <[email-masked]>,        'Nimish Bhargava'
>         <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> If the assumption is that message processing would halt on first failure,
> I
> can't see why a Diameter message might have more than one Failed-AVP AVP.
> The RFC 3588 mandates that there MUST be only one Result-Code AVP in an
> answer message & implies ("The value of the Result-Code AVP will provide
> information on the reason for the Failed-AVP AVP.") a relation b/w the
> Result-Code AVP & the Failed-AVP AVP, all the more reason on why there MAY
> be only one Failed-AVP AVP.
>
> However, all erroneous AVPs associated with the error (for eg: the
> "contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be
> filled in one Failed-AVP AVP only (the ABNF allows this provision)
>
>
>   _____
>
> From: Glen Zorn (gwz) [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2007 10:52 PM
> To: Nimish Bhargava; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Result code of Multiple failed Avps
>
>
>
> well it is not compulsory, diameter messages may contain multiple
> Failed-AVP
> avps.
> Right.
> As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and
> various applications specifications specify support for multiple
> Failed-AVP
> avps.
>
>
>
> On 1/9/07, Rajith R <[email-masked]> wrote:
>
> A Diameter message may contain one (and only one) Failed-AVP AVP.
> Not true.
>
>
>
>   _____
>
> From: Nimish Bhargava [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2007 5:19 PM
> To: [email-masked]
> Subject: [Dime] Result code of Multiple failed Avps
>
>
>
> Hi everyone
>
> While sending a response containing multiple failed AVPs, what should be
> the
> value of result code AVP?
> since different AVPs may fail due to different reasons, should the error
> code of the first failed AVP be sent as result code?
> I think that the assumption was that received message processing would
> halt
> on the first invalid AVP &  an error returned.  It might be a good idea to
> change the Failed-AVP to include an error code...
>
> Thanks
> Nimish
>
>
>
>
>
>
> --
> Real programmers don't work from 9 to 5. If any real programmers are
> around
> at 9am it's because they were up all night.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/dime/attachments/20070116/c269a5c5/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 16 Jan 2007 12:56:24 +0530
> From: Nimish Bhargava <[email-masked]>
> Subject: RE: [Dime] Result code of Multiple failed Avps
> To: [email-masked]
> Cc: [email-masked], "'Glen Zorn \(gwz\)'" <[email-masked]>
> Message-ID:
>         <
> [email-masked]
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> If we restrict the failed AVPs just on the basis of Result-Code AVP we may
> not be able to provide all the information regarding the failed AVPs to
> the application.
> Since the whole message still needs to be parsed in order to find out the
> AVPs failing due to a particular Result Code, it would be better to
> include a Result-Code AVP in the Failed-AVP ABNF.
>
> That way one can implement both the scenarios i.e. send AVPs failing due
> to a particular Result Code and sending Failed-AVPs citing multiple Result
> Codes.
>
> Regards,
> Nimish
>
>
>
>
> Rajith R <[email-masked]>
> 01/16/2007 11:30 AM
>
> Please respond to
> [email-masked]
>
>
> To
> "'Glen Zorn (gwz)'" <[email-masked]>, "'Nimish Bhargava'"
> <[email-masked]>
> cc
> [email-masked]
> Subject
> RE: [Dime] Result code of Multiple failed Avps
>
>
>
>
>
>
> If the assumption is that message processing would halt on first failure,
> I can't see why a Diameter message might have more than one Failed-AVP
> AVP. The RFC 3588 mandates that there MUST be only one Result-Code AVP in
> an answer message & implies ("The value of the Result-Code AVP will
> provide information on the reason for the Failed-AVP AVP.") a relation b/w
> the Result-Code AVP & the Failed-AVP AVP, all the more reason on why there
> MAY be only one Failed-AVP AVP.
>
> However, all erroneous AVPs associated with the error (for eg: the
> "contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be
> filled in one Failed-AVP AVP only (the ABNF allows this provision)
>
> From: Glen Zorn (gwz) [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2007 10:52 PM
> To: Nimish Bhargava; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Result code of Multiple failed Avps
>
>
> well it is not compulsory, diameter messages may contain multiple
> Failed-AVP avps.
> Right.
> As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and
> various applications specifications specify support for multiple
> Failed-AVP avps.
>
>
> On 1/9/07, Rajith R <[email-masked]> wrote:
> A Diameter message may contain one (and only one) Failed-AVP AVP.
> Not true.
>
> From: Nimish Bhargava [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2007 5:19 PM
> To: [email-masked]
> Subject: [Dime] Result code of Multiple failed Avps
>
> Hi everyone
>
> While sending a response containing multiple failed AVPs, what should be
> the value of result code AVP?
> since different AVPs may fail due to different reasons, should the error
> code of the first failed AVP be sent as result code?
> I think that the assumption was that received message processing would
> halt on the first invalid AVP &  an error returned.  It might be a good
> idea to change the Failed-AVP to include an error code...
>
> Thanks
> Nimish
>
>
>
>
> --
> Real programmers don't work from 9 to 5. If any real programmers are
> around at 9am it's because they were up all night.
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>
> ***********************  Aricent-Private   ***********************
> "DISCLAIMER: This message is proprietary to Aricent  and is intended
> solely for the use of
> the individual to whom it is addressed. It may contain privileged or
> confidential information and should not be
> circulated or used for any purpose other than for what it is intended. If
> you have received this message in error,
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for
> loss or damage arising from the use of the information transmitted by this
> email including damage from virus."
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/dime/attachments/20070116/65bf6b68/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Tue, 16 Jan 2007 13:05:48 +0100
> From: "Ulf Bodin" <[email-masked]>
> Subject: [Dime] RE: The Auditing Problem
> To: <[email-masked]>
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain;       charset="us-ascii"
>
> Folks,
>
> Following Hannes advice I've put together a first proposal for more
> detailed example scenarios/use cases.
>
> Before going into those use cases I just want to remind of the earlier
> discussion on applicability by repeating my opinion of that a good
> design approach would be to for a new application first explore if
> soft-state without auditing is sufficient before considering designing
> for auditing (in case we manage to specify a solution for auditing that
> is :-). Such an apporach is in my view beneficial since auditing adds
> complexity and creates excess signaling traffic (potentially at times
> when additional signaling load should be avoided).
>
> Anyway, considering applications for which auditing is deemed needed I
> beleive the following use cases to represent typical scenarios for which
> auditing provides a clear value.
>
> I'm starting with describing the last one (I think the hard-state use
> cases more clearly need auditing). Also, I believe the requirements to
> be quite similar for both client and server failover. Hence, for now I'm
> only considering server failover (i.e. to not take a too big bite too
> soon ... ).
>
> Use case 1: Hard-state without state replication
>
> In general this type of use case can be expected to only apply to
> low-volume and long holding-time applications. For such applications the
> overhead of performing state rebuild through auditing may be tolerated
> as it can spare resources (i.e. state replication may consume hardware
> (CPU and memory) and network resources).
>
> Use case TBD.
>
> Use case 2: Hard-state with replication
>
> Server failover
>
> This use case would be basically the same as use case 4 for server
> failover except that the period for which the server sB operats on
> inaccurate information will last until a management function terminates
> malicious states.
>
> Use case 3: Soft-state without replication
>
> Use case TBD.
>
> Use case 4: Soft-state with replication
>
> Server failover
>
> The application I have in mind for this use case is a resource
> reservation made by a client to ETSI TISPAN RACS. I think this use case
> should prefereably be agnostic to the particular application though.
> Hence, the text does not refer explicitly to this application (which I
> believe is a good example, but not necessarily the only example).
>
> Server (B) is a backup for server (A). States of server (A) is
> replicated via its database (a) (e.g. using high availability middleware
> for replicating data). Writing data to database (a) is asyncronous and
> so is the replication between the two databases.
>
> +------------+   1   +------------+   2   +---------------+
> | soft-state +------>+ soft-state +------>+ replicated    |
> | client (cA)+       | server (sA)|       | database (DBa)|
> +------------+       +------------+       +------+--------+
>                                                3 |
>                                                  v
> +------------+       +------------+       +---------------+
> | soft-state |       | soft-state |   5   | replicated    |
> | client (cB)+------>+ server (sB)|<------+ database (DBb)|
> +------------+   4   +------------+       +---------------+
>
> Now, say that the client cA "1" requests a service from server sA
> resulting in that a soft-state is created in this server. Server sA
> replies to the request in parallel with "2" storing the state in its
> database DBa, whereafter this database "3" replicates the state to
> database DBb. After cA receives the reply sA however craches and
> subsequent requests of this client will therefore go to sB (e.g.
> automatically selected through SCTP multihoming or gratuitous ARP for IP
> takeover). The change of server is transparant to the client.
>
> The state established by client cA may not have been written to database
> DBa before server sA crached. In case it was not written the state would
> not have been replicated to DBb either. Alternatively, the state may
> have been written to DBa, but not replicated to DBb. This means that
> when sB receives "4" a request from cB (which may has had sB as its
> primary server since before or also has switched from sA because it
> chrached) and uses the "5" obtained set of states from DBb, which is
> inaccurate. Consequently, sB will produce the wrong answer to cB. E.g.
> in case of RACS accept (or deny) a reservation request because it didn't
> know that the requested resources are already booked (or released) by
> cA.
>
> The state is indeed soft and client cA will hence eventually learn that
> it's no longer valid. Client cA will however believe the state to be
> valid for a period up to the timer value, which can be several hundereds
> of seconds. E.g. in case of reservations for telephony the mean holding
> time for calls can be in the order of 300 seconds and setting the timer
> to this value make sence since that keeps the signaling traffic for
> updates sufficiently low.
>
> An optimization of this use case using auditing is to have server sB ask
> its clients for lists of their respective active sessions (i.e. lists of
> active sessions IDs). Such auditing request would be triggered by the
> event of that sB learns that it has taken over clients from sA. Based on
> these lists sB can determine of sessions it believes being active are
> really terminated and identify active but unknown sessions. For sessions
> being unknown to sB it can chose to either just wait until they expires,
> or explicitly ask the clients for more information on those sessions
> (i.e. in order to completely or partly re-create the missing states).
> The benefit of auditing is in this use case the period for which sB
> operates on inaccurate information can be reduced to a few seconds
> instead of potentially several hundreds of seconds.
>
> To summarize; the auditing mechanisms involved in this use case are (1)
> request from server to client for all active sessions and (2) request
> from server to client for all details known by the client on a specific
> session.
>
> Comments?
>
> Best regards,
> Ulf
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: den 1 januari 2007 13:06
> To: Ulf Bodin; Tolga Asveren
> Cc: [email-masked]
> Subject: The Auditing Problem
>
> Hi Ulf,
> Hi Tolga,
>
> I think that the discussion triggered by Tolga was quite helpful in
> order to get a better understanding of the auditing work.
>
> What I would like to see is a more detailed example scenario (possibly
> with message flows). Tolga provided a scenario with a figure but it
> needs to be enhanced when it comes to the "service logic functionality".
>
> I think that this is important since there is a front-end and a back-end
> part to the entire story. The TISPAN QoS scenario has been mentioned as
> a potential customer of this work and it could be a nice example to see
> how the failure cases happen and how state is requested and moved
> around. I can imagine that there are a number of issues that need to be
> discussed when we jump into the details.
>
> I have also noticed that a number of terms are used without clearly
> describing them. For example, there are a number of different failover
> cases that need more description to ensure that we are on the same page.
>
> Another example: What is the definition for "session leaking"?
>
> Ciao
> Hannes
>
>
>
>
> ------------------------------
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
>
> End of DiME Digest, Vol 13, Issue 10
> ************************************
>
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime