Subject: [AAA-WG]: [issue] flag bit for start of conversation

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 May 2001 10:43:01 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 30-May-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

For use in load balancing, it can be important to easily discern 
whether a request constitutes the beginning of a conversation or not.
For example, if EAP is in use, there could be many requests within a given
conversation, and if the request were to be sent to another server in
the middle, ongoing conversations could fail. It does not appear to me
that any of the existing flag bits can be used to determine this. 

Requested change:
Addition of Flag bit to denote "start of conversation".

---

From: Mark Eklund <[email-masked]>
Date: Wed, 30 May 2001 16:24:35 -0400 (EDT)

Bernard,

You can use the Origin-FQDN from the reply of the initial
request as the Destination-FQDN for the requests following that.  
Does this accomplish what you are requesting?

-mark

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 May 2001 14:06:55 -0700 (PDT)

I am thinking mostly of an intermediary. Is use of the Destination-FQDN
for multi-round-trip conversations required? If so, then one can conclude
that any Request with a Destination-FQDN is a continuing conversation and
all other requests are new conversations. If it's not required, then some
other mechanism is required to figure this out.

---

From: Mark Eklund <[email-masked]>
Date: Wed, 30 May 2001 18:07:20 -0400 (EDT)

Bernard,

I don't think you can use Destination-FQDN as the sentinal.  
For example issue #48, "Destination-FQDN in re-auth Messages"
suggests as an option that if the server is unreachable, you MAY
resend the re-auth without a Destination-FQDN.

Could you give an example of how an intermediary would use the
information that this is continued conversation?  Your one
listed in the issue was more of a routing issue.

I can think of one way where your requested bit would be useful.  
If you get a AAR without a flag bit for start of conversation,
you will know that is a re-auth.  Of course, you could also look
in the session state table to see if the session already exists.

-mark

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 May 2001 16:35:38 -0700 (PDT)

> listed in the issue was more of a routing issue.

Assume we've got a stateless proxy load balancing between
connections to N servers. As described in
http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-03.txt we
might wish to hash on the NAI to decide which connection to use for a
given transaction. 

Say that one of the servers goes down. We now need to re-partition the
workload between N-1 connections. However, we do not want to move existing
connections to a new server, just new connections. Since this is a
stateless proxy, we don't have a table of conversations to use in order to
accomplish this. 

We would like to have a way to know if the transactions represents a new
connection so we can execute the following logic:

a. If it is a new connection, utilize the re-computed partition table to
assign it to a server. 

b. If it is an existing connection, utilize the previously computed
partition table to assign it to a server.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 30 May 2001 19:16:15 -0700

> stateless proxy, we don't have a table of conversations to use in order to

If this is required, then I agree that some way to signal an auth or re-auth is
desired.

In fact, I believe that it MAY also be useful to have such a bit to inform the
server that a message will create a session, and it should expect a session terminationm
message in the future. Of course, for re-auth messages, the bit wouldn't be set. Keep
in mind, though, that the Destination-FQDN is *always* present when the mesage is
destined for a particular server, and if this is the intent of your proposal, then
I still believe that the Destination-FQDN is sufficient. If the message
can be sent to any server within a realm, then the AVP wouldn't be present, and
stateless proxies could perform the necessary load balancing.

PatC