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

From: Jacques Caron <[email-masked]>
Date: Thu, 26 Jul 2001 19:19:34 +0200

At 18:52 26/07/01, Pat Calhoun wrote:
>Why, exactly, is it necessary for the same path to be taken
>for a given session? Doing so will reduce the reliability of
>the protocol, since an agent that is no longer available wouldn't
>be able to be used. If some mechanism is used to failover all
>sessions to the unavailable server is designed, then you still
>have to support the case where state was lost.
>
>So, this is just half a fix, IMHO. The real fix is to write something
>to a backend database, no local memory, and that's no a protocol issue.

Well, there are two cases:
- two (or more) agents in a load-balanced/failover setup
- two (or more) completely different paths via different administrative domains

Let's consider this:

ISP.NET client---ISP.NET proxy-----ROAMING1.NET proxy 1-----HOME.COM server
                      |                                          |
                      +-------------ROAMING1.NET proxy 2---------+
                      |                                          |
                      +-------------ROAMING2.NET proxy 1---------+
                      |                                          |
                      +-------------ROAMING2.NET proxy 2---------+

The ISP.NET proxy can reach HOME.COM either via ROAMING1.net, or via 
ROAMING2.NET. And both have two proxies. Picking any of the two proxies of 
one or the other is OK (provided the two proxies keep "in sync" somehow). 
But sending some stuff to ROAMING1.NET and some other to ROAMING2.NET might 
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.
>
>And I suppose the issue is that the Route-Records AVPs are removed at
>each hop in the routing of the answer messages.

We removed this :-) We might just want to make it explicit that 
Route-Records must be left unchanged (nothing added, nothing removed) when 
routing answers.

>Right. I honestly don't understand the problem here. We are going out
>of our way to add complexity to support a really bad model. Randy Bush
>has stated time and time again, that we MUST NOT add complexity throughout
>the protocol to support proxies. They are evil, and while the protocol
>does support them, adding more complexity shouldn't be done.

I don't think it adds that much complexity. The only changes are:
1. Server sends back the whole list of Route-Records it got in the answer
2. Explicitly state that relays/proxies don't touch Route-Records in answers
3. Client stores the list of Route-Records received in the latest answer 
for a session
4. Client uses this list as Source-Route AVPs in subsequent requests for 
the same session.
5. Explicitly state that proxies and relays ignore Destination-Host/Realm 
AVPs if Source-Route AVPs are present.

And even though proxies might be evil, they are THE fundamental part of the 
whole global roaming architecture, don't you think?

Jacques.

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

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Jul 2001 09:52:07 -0700

On Thu, Jul 26, 2001 at 10:39:53AM +0200, Martin Julien (ECE) wrote:
> > At 18:43 25/07/01, Martin Julien (ECE) wrote:
> > > > 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).
> > >
> > >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.
> > 
> > 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 :-)

> > 
> > > > 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.

This sure sounds EXACTLY like the Route-Record AVP.

> > >
> > >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.
> > 
> > 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.
> > 
> > >However, your previous solution is much simpler to implement,
> > >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 
> > solution below might actually be the simplest:
> > 
> > >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.
> > 

> > 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).
> 
> I guess that the order the Route-Record AVPs is read through is 
> different for a request than for an answer, without necessary 
> changing the order in the message. That would mean that when
> using those AVPs for routing, each node would have to go through
> the list of routing AVPs to find its own identity, and then 
> follows the routing scheme. It seems to work, at the cost of
> a slower routing process again.

My 2 cents,

PatC

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 26 Jul 2001 10:39:53 +0200

Martin

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Jul 2001 12:36:37 -0700

I'd like to get a rough idea from the WG on whether they believe this
is a valid approach. 

Anyone else agree, disagree, don't care?

PatC