Subject: [AAA-WG]: Issue 97: Proxies keeping a session-state

From: "Martin Julien (ECE)" <[email-masked]>
Date: Wed, 25 Jul 2001 16:41:53 +0200

Submitter name:  Martin Julien
Submitter email address:  [email-masked]
Date first submitted:  July 25, 2001
Reference: 
Document: Base-07
Comment type: T
Priority:  1
Section:  
Rationale/Explanation of issue:

It seems that the Source-Route AVP is mainly used to make
sure that a server-initiated request goes through the same
agents as the initial auth request from the client. The 
reason for that is that agents might be keeping a session
state, in which case they need to be aware of what is being
exchanged between the client and the server. However, the
way it is defined now does not let us take advantage of it, 
especially when the client can not even make sure that the 
next message it sends to the server will go through the 
same agents, since the load-balancing in relays could occur. 
I guess this should be fixed so that the client can be
assured that all the requests for the given session will
go through the necessary proxies that keep a session-state.

Requested change:

A possible way of making sure that messages go through the same agents
between the different requests from the client, and also the server-
initiated requests from the server, would be to support another routing
AVPs called Agent-Route AVP, which would be added in the first request
to the server, and returned to the client in the answer message. Then,
the second request from the client would include that AVP, for making 
sure that the message go through that agent. The server would also have 
to keep that AVP for server-initiated request towards the client. 

By doing so, we do not need the Source-Route AVP, and can come back to 
a more generic way of routing request.

---

From: Jacques Caron <[email-masked]>
Date: Wed, 25 Jul 2001 18:04:48 +0200

Hi,

>go through the necessary proxies that keep a session-state.

I had already submitted something along those lines in issue 83:
- If multiple hosts listed for a given realm (redirect, relay, proxy), use 
the same one for a given Session (either need to maintain Session state or 
to use some hash function based on Session-ID) unless error occurs (and 
then keep that one that works).

>a more generic way of routing request.

Let me try to understand what you mean exactly...
- first request of a session is sent without Agent-Route by client
- proxies/relays add Agent-Route records along the way (same thing as 
Route-Record?)
- server stores Agent-Route list, sends it in answer
- answers are routed back using saved transaction state, with the 
Agent-Route AVPs unchanged
- client stores Agent-Route AVPs.

Then, subsequent requests from the client for the same session will have 
the Agent-Route AVPs, and those will be used to route the request (no need 
for Route-Records, then?)
And unsolicited requests from the server would have the Agent-Route AVPs 
also (but reversed).

I see two issues:
- duplication of info with Route-Record
- how does a proxy/relay know whether the Agent-Route AVPs are to be used 
for routing, or for collection of the path?

I would actually change this to be this way rather:
- first request of a session is sent without Agent-Route by client
- proxies/relays add Route-Record AVPs along the way, as usual
- server stores Route-Record list, sends it in answer (AVP to be decided)
- answers are routed back using saved transaction state, with the list 
unchanged
- client stores the list

Then, nodes sending requests for the same sesion use the list (in forward 
or reverse order) within Source-Route AVPs, and proxies use it to 
proxy/relay. Of course, the usual Alternate-Proxy forwarding rules apply.

So the only change is actually to send the Route-Record list back to the 
origin so that it can be used to source-route subsequent requests. 
Proxies/relays should know that Route-Records in an Answer message are not 
to be changed.

Note that if an intermediate node fails and alternate routing is used, the 
new route-record set should probably be used from then on.

Jacques.

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

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Wed, 25 Jul 2001 18:43:33 +0200

Hi,

> then keep that one that works).

That is very interesting. Maybe something along those lines
should be mentionned in the draft, especially with regards
to selecting a consistent next-hop peer based on hashing of 
the session-id. I'd like to see that in the draft, since it
would fix that problem.

> - client stores Agent-Route AVPs.

No, my intention was to add the Agent-Route AVP only for the 
proxies that need to keep a session-state. If a proxy or a
relay does not keep a session-state, then no Agent-Route AVP 
should be added. In fact, I was thinking of using that 
AVP in the routing as the first routing option for request
messages, followed by the Destination-Host check, and then 
the Destination-Realm one.

However, your previous solution is much simpler to implement,
and still provide some kind of load-balancing.

> new route-record set should probably be used from then on.

Interesting, but still more complex than your previous suggestion.

Martin

---

From: Jacques Caron <[email-masked]>
Date: Wed, 25 Jul 2001 19:03:41 +0200

>the session-id. I'd like to see that in the draft, since it

There's actually an issue, which is that if the set of peers that can serve 
a request change (one goes down, a new one is added...), then obviously the 
hashing changes, and requests might get sent to another peer. There must be 
some clever way to handle that, though, if I scratch my head a bit more :-)

>should be added.

Mmmm... This might not work. Imagine you have this:

Client----Relay 1-------Relay 2------Proxy A------Relay 3-----Server
             |                                                   |
             +-----------Relay 4------Proxy B------Relay 5-------+

[stupid setup, but just for the example]. If only Proxy A says "please pick 
me rather than another proxy" (i.e. Proxy B), Relay 1 doesn't know that 
this means "go through Relay 2 rather than Relay 4".

However, it looks a bit like one of the suggestions I had on the routing of 
unsolicited requests:
>When a client sends a request to a server, it includes information on how 
>to establish a direct connection back (certificate...).
>If at some point there is a breach in IP reachability, the proxy/relay 
>that acts as a gateway between the two routing domains includes an AVP 
>stating that unsolicited requests should go to it rather than to the 
>Origin-Host directly (possibly including certificate info of its own), and 
>it will send it to the client. This can possibly happen multiple times, of 
>course. It can also be used if a proxy wants to check/modify any request 
>that is sent to a client. The AVP might contain multiple DiameterIdenties 
>to provide redundancy.
>If the request causes a change in the state of the session, the client 
>MUST send a regular request back to the server to update state in stateful 
>proxies (unless all these proxies add the "get it through me" AVP, which 
>might actually be the best solution).

This actually means that you "bypass" some of the intermediate relays to go 
directly to the "significant" hops. Probably not a good idea.

>and still provide some kind of load-balancing.

Well, in any case, load balancing occurs on the initial request in a 
session, and then subsequent requests should follow the same path (a bit 
like per-destination load balancing vs per-packet load-balancing on 
routers). And there is the issue above with "my solution". I think the 

>Proxies/relays should know that Route-Records in an Answer message are not 

It draws on the already-existing Route-Record & Source-route mechanism 
(with Alternates etc.) and requires just two changes:
- server returns the full list of Route-Records in answer [it already saves 
it for unsolicited requests]
- client saves it for future requests.

Of course, the list from Route-Record AVPs are to be inserted as 
Source-Route AVPs in different orders depending on who is sending the 
request (client or server).

Jacques.