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

From: Jonathan Wood <[email-masked]>
Date: Mon, 4 Jun 2001 15:11:17 -0700 (PDT)

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

Also, there is no Nagle for SCTP. I'll come up with some text for
this.

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

The first paragraph of section 2.5 implies that duplicates may
arrive as a result of transport-level retransmissions. However,
TCP and SCTP do their own duplicate detection, and so will not
pass these on to AAA. We could probably just remove the first
paragraph.

> > 
> > 8. editorial nit in 3.9.1
> > 
> > diamter->Diameter

Actually, it should be AAA in this document.

> > 
> > I honestly do not understand what the figure, or its explanation, really 
means
> 
> Will try to make it more clear. 

This diagram attempts to show a way to handle the case where
an agent needs to forward messages between two SCTP associations
that have different numbers of streams. I'll add some clarifying
text.
 
> > 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.
> 
> 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. 

The DRR is indeed elided in the text. We should clarify this.

> 
> > 
> > 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??
> 
> 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. 
> 
> > 
> > "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)
> 
> Failure is detected from the fact that watchdog timer has expired and the
> queue is not empty. 

Maybe we should include Allison and Randy's pseudo algorithm
in some form to help make this clearer? I agree it is a bit
tricky to follow just from the text.

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

Should read "The AAA client SHOULD wait for the transport layer
to report connection" success, but MAY chose to bound this wait
time by the watchdog interval, Tw."

The intent is to let the transport layer decide when a connection
attempt has failed (TCP and SCTP both retransmit and back off
connection attempts). However, in some cases, the RTO can
grow quite large, which means it may take minutes for the
transport to decide that a connection attempt has failed. The
second half of the sentence, "but MAY chose ..." gives the
AAA layer a way out of this, by limiting the wait time to
something more reasonable.

Let me know if you still think it needs fixing.

Jon

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 16:24:38 -0700

> tricky to follow just from the text.

I don't think so, but the paragraph should probably read "If a failure is detected,
and the queue is not empty, then failover is initiated..." That just makes so much
more sense.
> Let me know if you still think it needs fixing.
s/bound/bind/

PatC