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

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 27 Jul 2001 09:33:54 +0200

Hi Pat,

I must say that my opinion on this whole issue is that I much more
preferred the former way of routing messages using the Destination-Realm
and Destination-Host, especially for server-initiated messages. I
liked it and thought it was plenty enough for our needs at this
point.

The problem was that the Source-Route AVPs were introduced
in order to make sure that messages go through the same proxies
during all the session. However, with the actual 07 draft, it is
not possible to assure that all the requests from the client of
the session will go through the same set of agents, which I think
meant an incomplete solution for the problem that the Source-Route
AVPS tried to solve.

The real and fondamental question for this is: "Should the spec 
make sure that keeping Session-States in proxies is possible?"
If you think it is important, the spec should support
what Jacques has suggested. Otherwise, I would prefer coming back
to the former and much simpler way of routing using 
Destination-Realm and Destination-Host AVPs, and that the spec
does not mention that proxies might be expected to support
session-state, unless with a propriatory solution.

So, to be honest with you, we do not expect any of our agents up
to now to be maintaining session states.

I Hope it clarifies my point of view.
Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 9:37 PM
> To: Jacques Caron
> Cc: Pat Calhoun; Martin Julien (ECE); [email-masked]'
> Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state
> 
> 
> 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
> On Thu, Jul 26, 2001 at 07:19:34PM +0200, Jacques Caron wrote:
> > 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: Jacques Caron <[email-masked]>
Date: Fri, 27 Jul 2001 14:36:22 +0200

Hi,

I agree with Martin on the fact that either the same path must be taken in 
both directions, or there should be no provision for that at all.

However, even though I have no particular idea about what applications 
might need proxies to keep session state, that's a stated requirement for 
proxies, as far as I understand it. And seeing what happens in e.g. HTTP 
load balancers etc, there clearly is a need to have persistency to a given 
host (I do agree it's stupid and that people should rely on a common 
back-end, but there are many issues with that, including performance, 
etc.). Many people might be OK with two hosts not being "in sync" (via a 
back-end database or the exchange of "mirroring" information), and lose 
state in case of a host failure only (it's a matter of how much you are 
willing to "lose" in the event of a failure vs how much it costs to 
implement a given level of redundancy).

And then we need to make sure the path is kept. This simply means that the 
first request in a session is Destination-Realm/Host-routed, while all the 
subsequent ones are Source-Routed onto the path captured on this first request.

Note also that there are already provisions for hosts going down 
(Alternate-Host AVPs).

Finally, I think there is (was?) already something very similar with the 
use of Destination-Host in subsequent requests for the same session, 
actually. We're just extending and generalizing that to all hops on the 
path rather than just the last one.

Jacques.

At 13:41 27/07/01, Fredrik Johansson wrote:
>Hi all,
>
>I agree with Martin. I prefer to go back to the old way of routing. Why
>should it be different in the backward direction than in the forward
>direction? It would make the protocol a lot simpler if we route on
>destination-host and realm in both directions. And also less vulnerable to
>host going down.
>
>my 2c
>
>/Fredrik
>
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of
> >Martin Julien (ECE)
> >Sent: den 27 juli 2001 09:34
> >To: 'Pat Calhoun'; Jacques Caron
> >Cc: Martin Julien (ECE); [email-masked]'
> >Subject: RE: [AAA-WG]: Issue 97: Proxies keeping a session-state
> >
> >
> >Hi Pat,
> >

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Jul 2001 07:01:08 -0700

> liked it and thought it was plenty enough for our needs at this

Me too, and I stated on the list that was my preference (and others in
the design team). I sent a mail to the list, requesting that without the
change I proposed, it would require additional configuration that doesn't 
existing in today's networks, and I didn't think this was much of an issue.

I proposed text, and asked for folks to shoot it down, and no one did, so
the text got included in the base spec :(

> meant an incomplete solution for the problem that the Source-Route

Well, the solution also allows for alternates to be used, should an agent
no longer be reachable.

> make sure that keeping Session-States in proxies is possible?"

Good question.

> session-state, unless with a propriatory solution.

Right, and proprietary hacks will always exist. The real question is
how far out of our way do we need to go to support proxies. Randy says
very little, other folks say all the way.

> to now to be maintaining session states.

good :)

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Jul 2001 07:01:59 -0700

> destination-host and realm in both directions. And also less vulnerable to

Well, it would have been nice to hear that when I asked the WG, instead
of after no one responded and I included the new text in the spec. Perhaps
we can discuss this in London.

PatC