Subject: [AAA-WG]: Issue 70: Caching of redirects

From: Pat Calhoun <[email-masked]>
Date: Thu, 7 Jun 2001 17:42:29 -0700

All,

The following text reflects the decision that was taken during today's
discussion, and I'd like to get any WG comments on the proposed text.

5.9  Recommended-Redirect-Cache-Time AVP

   The Recommended-Redirect-Cache-Time AVP (AVP Code TBD) is of type
   Unsigned32. This AVP MUST be present in Message-Reject-Answer
   messages that include the Result-Code AVP set to
   DIAMETER_REDIRECT_INDICATION.

   This AVP contains the maximum number of seconds the redirector
   recommends when caching any route entries resulting from the MRA
   message.

5.10  Redirect-Host-Usage AVP

   The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated.
   This AVP MAY be present in Message-Reject-Answer messages that
   include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION.

   When present, this AVP dictates how the routing entry resulting from
   the MRA is to be used. The following values are supported:

      ALL_REALM                         0
         All messages destined for the realm requested MAY be sent to
         the host specified in the Redirect-Host AVP. This is the
         default value.

      REALM_AND_APPLICATION             1
         All messages for the application requested to the realm
         specified MAY be sent to the host specified in the Redirect-
         Host AVP.

Thanks,

PatC

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Jun 2001 11:20:06 +0200

Hi,

Sorry I couldn't get on the call. I think it would be useful to also have a 
value for not allowing caching. I guess it could be implicitly done with a 
value of 0 for Recommanded-Redirect-Cache-Time, but that should be stated 
as such? And since it's recommended only, that might not be strong enough?

Jacques.

>          specified MAY be sent to the host specified in the Redirect-

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Mark Eklund <[email-masked]>
Date: Fri, 8 Jun 2001 09:50:54 -0400 (EDT)

Jacques, 

To not allow caching, would adding the following statement be
sufficient?

5.10  Redirect-Host-Usage AVP
    ... If the Redirect-Host-Usage AVP is not present, this
    redirect may be used for this transaction only. ...

-mark

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Jun 2001 16:02:04 +0200

>     redirect may be used for this transaction only. ...

This contradicts the fact that ALL_REALM is the default. I see the 
following options:
1. State that a value of 0 for Recommended-Redirect-Cache-Time means no 
caching (and is not recommended but mandatory in this case?)

2. Add a new value for Redirect-Host-Usage:
         DONT_CACHE                      2
                 The host specified in the Redirect-Host AVP should not
                 be cached.

3. State that when Redirect-Host-Usage is not present, no caching is to be 
done by changing the text to:

   When present, this AVP dictates how the routing entry resulting from
   the MRA is to be used. If absent, the results should not be cached.
    The following values are supported:

And removing the "This is the default value" for ALL_REALM.

In the latter two cases, it makes no sense to make 
Recommended-Redirect-Cache-Time mandatory, though.

Jacques.

---

From: Mark Eklund <[email-masked]>
Date: Fri, 8 Jun 2001 10:45:00 -0400 (EDT)

Jacques,

> This contradicts the fact that ALL_REALM is the default. I see the 

Whoops, I missed the statement saying ALL_REALM is default.

>                  The host specified in the Redirect-Host AVP should not

I would like a prefer a slight variation on this.  Add a
DONT_CACHE value, make it the first one, and make it default.  
That way, you don't cache unless you are told that caching is
allowed.

-mark

---

From: Mark Eklund <[email-masked]>
Date: Fri, 8 Jun 2001 11:12:38 -0400 (EDT)

Jacques,

I don't know why cache time is "recommended" either.

I prefer DONT_CACHE to be default because in the case where you
aren't caching, you will have the most traffic.  So not having
that AVP when there is the most traffic makes sense to me.

-mark

On Fri, 8 Jun 2001, Jacques Caron wrote:

> At 16:45 08/06/01, Mark Eklund wrote:
> I agree with making it the first one, it's more logical. I thought about 
> making it the default, but I'm not so sure. It depends what we expect would 
> be the default behaviour, actually. And then it raises the issue of the 
> mandatory clause for the caching time.
> 
> In fact, I would reverse the descriptions for the two AVPs, make DONT_CACHE 
> first, and state for the others that in those cases one can specify the 
> caching time with the other AVP.
> 
> In the cache time AVP I would then probably add a default value... Though I 
> don't know how much that should be (5 minutes, an hour, a day...)?
> 
> Still wonder why it should be "recommended" only, though?
> 
> Jacques.
> 
>

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Jun 2001 16:53:04 +0200

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 8 Jun 2001 09:37:27 -0700

> I don't know why cache time is "recommended" either.

Well, we can make it a MUST instead of a recommendation. But
what happens if one doesn't cache entries? Are they non-conformant?

PatC

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Jun 2001 19:06:31 +0200

>what happens if one doesn't cache entries? Are they non-conformant?

I'd at least say that the host sending the request MUST NOT cache the 
redirect-Host longer than the value of the AVP. Doesn't force it to cache, 
but makes sure that it doesn't cache it longer than the redirector wants.

You can see that a bit like DNS TTL or HTTP expiration (or whatever it's 
nowadays in Cache-Control). Nothing prevents the requestor/proxy from 
forgetting immediately about it, but it should not keep it longer than 
indicated.

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 8 Jun 2001 10:06:26 -0700

On Fri, Jun 08, 2001 at 01:14:34PM -0400, Mark Eklund wrote:
> Pat, I agree with Jacques.  Maybe a name of I was thinking
> Maximum-Redirect-Cache-Time makes more sense.

sounds good.
> 
> One question.  We mentioned creating a default value for
> Maximum-Redirect-Cache-Time.  This would only be true if it
> isn't required in a Message-Reject-Answer of type
> DIAMETER_REDIRECT_INDICATION.  Should it no longer be required
> and just have a default value if not present?

That works for me if the default is to cache.

patC

---

From: Mark Eklund <[email-masked]>
Date: Fri, 8 Jun 2001 13:14:34 -0400 (EDT)

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 12 Jun 2001 08:32:45 -0700

Taking all of the comments on the list on this issue, I've come up with the
following text.

Comments appreciated,

PatC
----

      DONT_CACHE                        0
         The host specified in the Redirect-Host AVP should not be
         cached. This is the default value.

      ALL_REALM                         1
         All messages destined for the realm requested MAY be sent to
         the host specified in the Redirect-Host AVP.

      REALM_AND_APPLICATION             2

5.11  Maximum-Redirect-Cache-Time AVP

   The Maximum-Redirect-Cache-Time AVP (AVP Code TBD) is of type
   Unsigned32. This AVP MUST be present in Message-Reject-Answer
   messages that include the Result-Code AVP set to
   DIAMETER_REDIRECT_INDICATION, and the Redirect-Host-Usage AVP set to
   a non-zero value.

   This AVP contains the maximum number of seconds the peer and route
   table entries, created as a result of the Redirect-Host, must be
   cached.

---

From: Mark Eklund <[email-masked]>
Date: Tue, 12 Jun 2001 11:51:25 -0400 (EDT)

Pat,

Looks good.  One nit.

>    table entries, created as a result of the Redirect-Host, must be

Can we change the above "must" to a "will".

-mark

---

From: Jacques Caron <[email-masked]>
Date: Tue, 12 Jun 2001 20:40:26 +0200

Pat,

Please see comments inline.

      When present, this AVP dictates how the routing entry resulting from
      the MRA is to be cached for use in subsequent related requests. The

>          cached. This is the default value.

         ALL_SESSION                        1
            All messages within the same session, as defined by the same
            value of the Session-ID AVP MAY be sent to the host specified
            in the Redirect-Host AVP.

[...though I should probably read whatever is the current state of 
discussion on Session-ID and Multi-Session-ID... Please fix as deemed 
appropriate]

[shift the following two by one]

>          specified MAY be sent to the host specified in the Redirect-

         ALL_APPLICATION                    4
            All messages for the application requested MAY be sent to the
            host specified in the Redirect-Host AVP.

[don't know what it would be used for, but it just seems logical to have]

         ALL_HOST                           5
            All messages that would be sent to the host that generated the
            MRA MAY be sent to the host specified in the Redirect-Host AVP.

[Might be useful when a given server is about to be shut down for 
maintenance, for instance]

An alternative way of doing things would be to have an AVP that would list 
a set of AVP codes that must match with the current one's to be sent to the 
same host. More complex, but way more tailorable to everybody's needs.

>    DIAMETER_REDIRECT_INDICATION, and the Redirect-Host-Usage AVP set to

Could change MUST to may, and then make cache expiration a purely local 
decision?

>    table entries, created as a result of the Redirect-Host, must be

must -> can/is allowed to?

Probably also need to add something somewhere that states that all cache 
entries that send to a given host should be expired right away if the 
connection to said host goes down?

Jacques.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 13 Jun 2001 18:13:05 -0700

> Taking all of the comments on the list on this issue, I've come 

Works for me.