Subject: RE: [diameter] RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)

From: Patrice Calhoun <[email-masked]>
Date: Mon, 9 Apr 2001 11:41:22 -0700

>> So caching has its own problems, since it is possible for the next hop server
>> to have lost contact with a set of servers in the home domain, and caching
>> information locally will ensure that these new servers will never get to
>> provide services through the caching server.
>
>Yes. If you cache you also need a TTL. 
>
>The question is whether multiple transmissions are necessary each time you
>have message with inappropriate capabilities. You could send a lot of
>unnecessary traffic that way. Since proxies are already presumably
>maintaining routing tables, one wonders if those tables might also not
>contain capabilities for the domains in question.
>
Which only works if the next hop is the home domain. So perhaps a new AVP is
required so a server can state what it's home domain(s) are. This would allow
a server to know if the next hop is the home server, and it could then cache.

This would allow the protocol to operate when there is a more complex proxy
chain.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 9 Apr 2001 11:46:05 -0700

>> Correct, and this is returned as a per-hop error. So if the home server
>> returns such an error stating that it cannot support the extension, the
>> downstream proxy will attempt to re-route the message to another server
>within
>> the home domain. 
>
>I presume that the proxy would have used the DRI message in setting up
>connections with the servers within the home domain, right? So presumably,
>wouldn't it know what the capabilities were? I guess this might happen if
>a connection weren't already up, in which case the proxy would have to
>bring one up with the home domain. 

I *think* I understand the confusion. A DRI is a non-proxiable message. It is
hop-by-hop. So it is only received/processed by the home domain if the next
hop *is* the home domain.

>
>> So in the first case, since the home servers explicitely advertise support
>for
>> Mobile IP, there is no problem. In the latter case, it would require a
>> downstream proxy to send it to more than one server before finding a server
>> that supports Mobile IP.
>
>And if there is no server that supports Mobile IP, then an error is passed
>back from the proxy to the NAS, right?

yes.

> Question: given that the proxy has
>now investigated the capabilities of the domain in question, wouldn't it
>be able to respond right away to future requests? How long do the
>negotiated capabilities remain in effect? For the life of the
>connection? Is there some TTL associated with them?

Again, this is *only* valid if the home server *is* the next hop. You cannot 
cache if there are many hops since you could cache invalid data (e.g. perhaps
the mobile ip server was temporarily down, so a proxy had to return an error
to the upstream proxy). A request 10 seconds later could be completed since
perhaps the server would be back online.

>
>Also, does it make sense for the proxy to pass back to the NAS the list of
>extensions that *are* supported within the domain in question? In other
>words, should it pass back an Extension-Id AVP along with the error
>message?

well we could, but we've never done that before, and extensions MAY be supported
by different servers. So how would you return the list? A concatenated list of
all servers in the home domain? Do you have an association with all servers in
the home domain.

I think that what you are describing here is not really worth the cost.

>
>> This language is already there, and doesn't belong in the capabilities
>> exchange, but rather in the hop-by-hop errors section (and is present in
>> section 9.0). Please let me know if additional language is required in that
>> section.
>
>This is a case where there needs to be a section giving an overview of how
>the protocol functions so that the behavior is described. You can leave
>the detailed descriptions in individual sections if you like, but having
>an overview somewhere would be helpful.

ok, I will add two new sections in the Protocol Overview section; end-to-end
and hop-by-hop behaviors.

PatC