Subject: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 09:07:39 -0700

All,

First, sorry if I'm jumping all over the document, but I am trying to read
the problem statement (section 2), and then the solution (section 3), and
at times, the section numbers don't necessarily line up (e.g. sections 2.5
and 3.6 discuss duplicates). So, I am not asking that the document be 
re-arranged, I am just justifying why my comments aren't linear.

PatC
----

1. Conflicting Nagle info

Section 2.3 states "... the Nagle algorithm [12] is ineffective.", while
section 3.3 states "AAA implementations MUST enable the Nagle algorithm, RFC
896 [12]."

So if it is ineffective, why is it's support mandatory?

2. Multiple Connections

Section 3.4 states "AAA protocols SHOULD use only a single persistent
connection between a AAA client and a AAA proxy or server...". I have two
issues with this text:

       a. The current base protocol's state machine goes out of its way
          to ensure that there is only one connection between two peers
	  by running an election process when two connections are received.
	  This text states that it is possible to have multiple connections.
	  Is this required, or not? One of the documents will need to change.
       b. The new and improved base protocol makes use of the term agent
          to represent relay, redirect and proxies. Perhaps you want to
	  use this overloaded term instead of proxy.

3. editorial nits in 2.5

The following is wrong "... to cache responses so as to make it possible
respond to such duplicate requests more efficiently."

I am not sure what the implications are of the following sentence "As a
result, AAA servers must be prepared to detect duplicate requests sent to
multiple servers." This implies inter-server communication of e2e ids, I
think.

The last sentence in this section implies that a duplicate is ignored, while
in the earlier paragraph it states that one should cache responses to handle
duplicates.

4. Editorial nits in 3.5

The first paragraph that head of line blocking isn't ameliorated since
only a single connection is in use at a time. I assume that this text was
targetted specifically for TCP, and NOT SCTP that supports streams, right?
btw, the following paragraph sort-of discusses this, but this is misleading.

The second paragraph discusses multiple connections, and I understand that
this is between two peers, but the first paragraph introduces primary
and secondaries. This then sort-of questions whether we are talking about
multiple connections to a single server, or to the primary/alts.

Bullet item one is in direct conflict with the actual protocol. Do we really
want multiple connections?

"Note that this requires a way to easily to determine whether a Request
represents a new conversation or the continuation of an existing
conversation." First off, "... to easily to ..." needs to be fixed. Second,
the protocol doesn't really require this, but instead a way for a sender
to state whether a message needs to be sent to a specific server is required.
This is handled via the Desination-Host AVP (yes, all *-FQDNs have been
changed to reflect the server identity issue).

"...transactions that were to have been assigned..." perhaps should be changed
to "... transactions that should have been assigned..." Further, I am not
sure what this text really states. I presume that you aren't stating that if
a message is destined for a particular server, based on the message's 
Destination-Host AVP, it should be sent to another server instead. Surely this
could be done as an optimization if the servers were redundant, but this
doesn't belong in the spec. Perhaps you really meant based on the 
hash table, right?

"Similarly, re-opened connections not accumulating sufficient watchdog
responses do not force a reconfiguration until they are returned to service."
This implies that although a connection has been established with a peer,
and according to the state machine it would be in the open state, it really
shouldn't be used for some time. If this is true, does it need to be reflected
in the state machine, or this is text sufficient?

What is a table of transaction outcomes? You mean simple stats?

5. Nit in 3.6

"AAA protocols MUST support an end-to-end message identifier, to enable
the home server to detect duplicates." This reads as if the protocol
is missing something, and it is supported in Diameter. Perhaps change the
sentence so it doesn't read as a requirement of a missing feature.

6. Clarification in 3.8 required

Although if one was to look at RFC 2861, it would be obvious, this whole
section doesn't make it clear that this is specifically for TCP (I believe
since RFC 2861 is specifically for TCP). Perhaps SCTP has this feature
built-in, or not. What does one do in regards to SCTP?

ummm... same comment for 3.7

7. Terminology in 2.8 is inconsistent with base protocol

The term store and forward and transport proxies is used, but never
discussed in the base protocol. I would remove these, and perhaps even
use agents instead of intermediaries.

8. editorial nit in 3.9.1

diamter->Diameter

I honestly do not understand what the figure, or its explanation, really means

9. app vs. net driven 

The more usage of these terms I see in the spec, the more I believe they
need to be defined in the terminology section. 

10. Clarification required in 3.11

The text implies that only the NAS performs failover. However, the base
protocol allows agents to handle failover, reducing the latency required
by the NAS in receiving a response. So, only the agent (or client) that
notices that its peer is unavailable is the one that handles the
failover.

Is this section implying that the base protocol needs to change?

11. Inconsistency between 3.1 and Issue 2

While the transport draft states that a NAS MUST support TCP, and MAY support
SCTP, issue two states that a NAS MUST support one of the two. This was the
decision at the interim meeting, from comments generated on the list that
the text in the transport draft doesn't allow an SCTP only client.

12. Questions on section 3.2

What does "The watchdog is also used to re-open and validate connections
that have returned to health." mean? The state machine requires that the
DRR be used to set the state to open, not the watchdog.

The text reads that the watchdog may be used with primary/secondary
or load balancing configurations, but these concepts are introduced
in later sections. Either include a reference, or change the order of
the sections.

"Watchdog packets are not retransmitted where AAA protocols operate over
reliable transports." Huh??

"If the queue is not empty, then failover is initiated..." something is
missing here. Somehow failover is detected, but it appears a little
too "out of the blue" (for lack of better terms.... and caffein)

"Once the primary connection has failed, subsequent requests are sent to the
alternate server until the watchdog timer on the primary connection
is reset." if the connection has failed, how does one send watchdogs?

"The AAA client SHOULD wait to the transport to report connection" doesn't
read right, as does "but MAY chose to bound this wait time by the watchdog
interval, Tw."

"Once three watchdog messages have been sent and responded to, the connection
is returned to service, and transactions are once again sent over
it." is inconsistent with the base protocol state machine. Do we need 
to fix the base, or leave this as an implementation issue?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Jun 2001 12:21:42 -0700 (PDT)

> section 3.3 states "AAA implementations MUST enable the Nagle algorithm, RFC

It's only effective when requests are spaced closer together than the
RTT. That's not usually the case, but when it is, Nagling is useful. I'll
clarify the language on this. 

> 	  Is this required, or not? One of the documents will need to change.

It was a SHOULD because making it mandatory seemed too harsh. I'm not
clear that allowing two connections for some short period of time is
really that bad, for example. If this would simplify the state machine,
then I think it would be a good tradeoff. 

> 	  use this overloaded term instead of proxy.

Actually I was intending to substitute the term "agent" for
"intermediary". Where the term proxy is used, it really does mean proxy,
not all agent types (at least I think so... )

> multiple servers." This implies inter-server communication of e2e ids, I

In practice it means having an accounting system that can weed out
dupes once received. If doing simultaneous usage assessment, it would mean
caching the response or including the session-id in the database so that
if a duplicate request comes in, you wouldn't send a Reject because the
person was already logged in once.

> in the earlier paragraph it states that one should cache responses to handle

I think that ignoring dupes is a bad idea. The goal should be to send the
same response. Whether that results from caching or not is an
implementation issue. 

> targetted specifically for TCP, and NOT SCTP that supports streams, right?

Yes. Will clarify. 

> multiple connections to a single server, or to the primary/alts.

This is multiple connections to different peers, not the same peer. 

> want multiple connections?

Don't think there's a conflict because it's about multiple peers. 

> changed to reflect the server identity issue).

The question is whether the Destination-Host AVP MUST always be
present in continuing conversations and MUST NOT be present in new
conversations. If so, then this would be a suitable
mechanism: if it's there, it's a continuing conversation, otherwise a new
one. 

> doesn't belong in the spec. Perhaps you really meant based on the 

If a message has a Destination-Host AVP then it should be sent to that
destination, UNLESS the destination is no longer available. Then it either
is dropped, an error message is sent, or it is sent to another
server. What is the appropriate action?

> in the state machine, or this is text sufficient?

I think that it does need to be reflected in the state machine. Note that
this is only for re-opened connections, though, not new ones. 

> What is a table of transaction outcomes? You mean simple stats?

Yes.

> sentence so it doesn't read as a requirement of a missing feature.

Sure. That section was put in before this feature was added. 

> ummm... same comment for 3.7

Will fix. 

> use agents instead of intermediaries.

Yup. Will change "intermediaries" to "agents". It's ok if S&F and
Transport proxies aren't discussed in base -- as noted in the Appendix
they're not all that useful. 

> I honestly do not understand what the figure, or its explanation, really means

Will try to make it more clear. 

> need to be defined in the terminology section. 

OK. Will do. 
> Is this section implying that the base protocol needs to change?

No. The term NAS should probably be changed to "AAA client". Agents can
indeed to failover. 

> the text in the transport draft doesn't allow an SCTP only client.

OK. Is there text somewhere that should be inserted here?

> DRR be used to set the state to open, not the watchdog.

It means that when a connection is re-opened after being closed, that it
should not be used immediately until it is determined that the watchdog
can be transported reliably.  This could result in flapping during
periods where there are connectivity problems. 

> reliable transports." Huh??

Jon added this, to mean that the app does not send another watchdog, the
re-transmission is handled by the transport. Will try to make it more
clear. 

> too "out of the blue" (for lack of better terms.... and caffein)

Failure is detected from the fact that watchdog timer has expired and the
queue is not empty. 

> is reset." if the connection has failed, how does one send watchdogs?

The connection has not been reset and so it is still open. However,
the watchdog timer continues to run. It is possible that a watchdog
response will eventually arrive. If another watchdog timer expires, the
connection is closed. If the response arrives, then the connection can be
marked as "available" again. 

> to fix the base, or leave this as an implementation issue?

I think that there is a state machine change required for this.