size of the requests, since SCTP tracks the progress for the opening
of the congestion window by bytes, not segments.
Note that [RFC2861] and [RFC2988] do not address the issue of RTO
validation. This is also a problem, particularly when the Congestion
Manager [RFC3124] is implemented. During periods of high packet
loss, the RTO may be repeatedly increased via exponential back-off,
and may attain a high value. Due to lack of timely feedback on RTT
and RTO during application-driven periods, the high RTO estimate may
persist long after the conditions that generated it have dissipated.
RTO validation MAY be used to address this issue for TCP, via the
following procedure:
After the congestion window is decayed according to [RFC2861],
reset the estimated RTO to 3 seconds. After the next packet comes
in, re-calculate RTTavg, RTTdev, and RTO according to the method
described in [RFC2581].
To address this issue for SCTP, AAA implementations SHOULD use SCTP
heartbeats. [RFC2960] states that heartbeats should be enabled by
default, with an interval of 30 seconds. If this interval proves to
be too long to resolve this issue, AAA implementations MAY reduce the
heartbeat interval.
3.7. Inability to Use Fast Re-Transmit
When Congestion Window Validation [RFC2861] is used, AAA
implementations will operate with a congestion window equal to the
initial window much of the time. As a result, the window size will
often not be large enough to enable use of fast re-transmit for TCP.
In addition, since AAA traffic is two-way, ACKs carrying data will
not count towards triggering fast re-transmit. SCTP is less likely
to encounter this issue, so the measures described below apply to
TCP.
To address this issue, AAA implementations SHOULD support selective
acknowledgement as described in [RFC2018] and [RFC2883]. AAA
implementations SHOULD also implement Limited Transmit for TCP, as
described in [RFC3042]. Rather than reducing the number of duplicate
ACKs required for triggering fast recovery, which would increase the
number of inappropriate re-transmissions, Limited Transmit enables
the window size be increased, thus enabling the sending of additional
packets which in turn may trigger fast re-transmit without a change
to the algorithm.
However, if congestion window validation [RFC2861] is implemented,
this proposal will only have an effect in situations where the time
between packets is less than the estimated retransmission timeout
(RTO). If the time between packets is greater than RTO, additional
packets will typically not be available for sending so as to take
advantage of the increased window size. As a result, AAA protocols
will typically operate with the lowest possible congestion window
size, resulting in a re-transmission timeout for every lost packet.
3.8. Head of Line Blocking
TCP inherently does not provide a solution to the head-of-line
blocking problem, although its effects can be lessened by
implementation of Limited Transmit [RFC3042], and connection load
balancing.
3.8.1. Using SCTP Streams to Prevent Head of Line Blocking
Each AAA node SHOULD distribute its messages evenly across the range
of SCTP streams that it and its peer have agreed upon. (A lost
message in one stream will not cause any other streams to block.) A
trivial and effective implementation of this simply increments a
counter for the stream ID to send on. When the counter reaches the
maximum number of streams for the association, it resets to 0.
AAA peers MUST be able to accept messages on any stream. Note that
streams are used *solely* to prevent head-of-the-line blocking. All
identifying information is carried within the Diameter payload.
Messages distributed across multiple streams may not be received in
the order they are sent.
SCTP peers can allocate up to 65535 streams for an association. The
cost for idle streams may or may not be zero, depending on the
implementation, and the cost for non-idle streams is always greater
than 0. So administrators may wish to limit the number of possible
streams on their diameter nodes according to the resources (i.e.
memory, CPU power, etc.) of a particular node.
On a Diameter client, the number of streams may be determined by the
maximum number of peak users on the NAS. If a stream is available
per user, then this should be sufficient to prevent head-of-line
blocking. On a Diameter proxy, the number of streams may be
determined by the maximum number of peak sessions in progress from
that proxy to each downstream AAA server.
Stream IDs do not need to be preserved by relay agents. This
simplifies implementation, as agents can easily handle forwarding
between two associations with different numbers of streams. For
example, consider the following case, where a relay server DRL
forwards messages between a NAS and a home server, HMS. The NAS and
DRL have agreed upon 1000 streams for their association, and DRL and
HMS have agreed upon 2000 streams for their association. The
following figure shows the message flow from NAS to HMS via DRL, and
the stream ID assignments for each message:
+------+ +------+ +------+
| | | | | |
| NAS | ---------> | DRL | ---------> | HMS |
| | | | | |
+------+ 1000 streams +------+ 2000 streams +------+
msg 1: str id 0 msg 1: str id 0
msg 2: str id 1 msg 2: str id 1
...
msg 1000: str id 999 msg 1000: str id 999
msg 1001: str id 0 msg 1001: str id 1000
DRL can forward messages 1 through 1000 to HMS using the same stream
ID that NAS used to send to DRL. However, since the NAS / DRL
association has only 1000 streams, NAS wraps around to stream ID 0
when sending message 1001. The DRL / HMS association, on the other
hand, has 2000 streams, so DRL can reassign message 1001 to stream ID
1000 when forwarding it on to HMS.
This distribution scheme acts like a hash table. It is possible, yet
unlikely, that two messages will end up in the same stream, and even
less likely that there will be message loss resulting in blocking
when this happens. If it does turn out to be a problem, local
administrators can increase the number of streams on their nodes to
improve performance.
3.9. Congestion Avoidance
In order to improve upon default timer estimates, AAA implementations
MAY implement the Congestion Manager (CM) [RFC3124]. CM is an end-
system module that:
(i) Enables an ensemble of multiple concurrent streams from a
sender destined to the same receiver and sharing the same
congestion properties to perform proper congestion avoidance
and control, and
(ii) Allows applications to easily adapt to network congestion.
The CM helps integrate congestion management across all applications
and transport protocols. The CM maintains congestion parameters
(available aggregate and per-stream bandwidth, per-receiver round-
trip times, etc.) and exports an API that enables applications to
learn about network characteristics, pass information to the CM,
share congestion information with each other, and schedule data
transmissions.
The CM enables the AAA application to access transport parameters
(RTTavg, RTTdev) via callbacks. RTO estimates are currently not
available via the callback interface, though they probably should be.
Where available, transport parameters SHOULD be used to improve upon
default timer values.
3.10. Premature Failover
Premature failover is prevented by the watchdog functionality
described above. If the next hop does not return a reply, the AAA
client will send a watchdog message to it to verify liveness. If a
watchdog reply is received, then the AAA client will know that the
next hop server is functioning at the application layer. As a
result, it is only necessary to provide terminal error messages, such
as the following:
"Busy": agent/Server too busy to handle additional requests, NAS
should failover all requests to another agent/server.
"Can't Locate": agent can't locate the AAA server for the
indicated realm; NAS should failover that request to another
proxy.
"Can't Forward": agent has tried both primary and secondary AAA
servers with no response; NAS should failover the request to
another agent.
Note that these messages differ in their scope. The "Busy" message
tells the NAS that the agent/server is too busy for ANY request. The
"Can't Locate" and "Can't Forward" messages indicate that the
ultimate destination cannot be reached or isn't responding, implying
per-request failover.
4. Security Considerations
Since AAA clients, agents and servers serve as network access
gatekeepers, they are tempting targets for attackers. General
security considerations concerning TCP congestion control are
discussed in [RFC2581]. However, there are some additional
considerations that apply to this specification.
By enabling failover between AAA agents, this specification improves
the resilience of AAA applications. However, it may also open
avenues for denial of service attacks.
The failover algorithm is driven by lack of response to AAA requests
and watchdog packets. On a lightly loaded network where AAA
responses would not be received prior to expiration of the watchdog
timer, an attacker can swamp the network, causing watchdog packets to
be dropped. This will cause the AAA client to switch to another AAA
agent, where the attack can be repeated. By causing the AAA client
to cycle between AAA agents, service can be denied to users desiring
network access.
Where TLS [RFC2246] is being used to provide AAA security, there will
be a vulnerability to spoofed reset packets, as well as other
transport layer denial of service attacks (e.g. SYN flooding). Since
SCTP offers improved denial of service resilience compared with TCP,
where AAA applications run over SCTP, this can be mitigated to some
extent.
Where IPsec [RFC2401] is used to provide security, it is important
that IPsec policy require IPsec on incoming packets. In order to
enable a AAA client to determine what security mechanisms are in use
on an agent or server without prior knowledge, it may be tempting to
initiate a connection in the clear, and then to have the AAA agent
respond with IKE [RFC2409]. While this approach minimizes required
client configuration, it increases the vulnerability to denial of
service attack, since a connection request can now not only tie up
transport resources, but also resources within the IKE
implementation.
5. IANA Considerations
This document does not create any new number spaces for IANA
administration.
References
6.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC896] Nagle, J., "Congestion Control in IP/TCP internetworks",
RFC896, January 1984.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC1750, December 1994.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC2018, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC2486, January 1999.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC2581, April 1999.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A.
Romanow, "An Extension to the Selective Acknowledgment
(SACK) Option for TCP", RFC2883, July 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
L. and V. Paxson, "Stream Control Transmission Protocol",
RFC2960, October 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC2988, November 2000.
[RFC3042] Allman, M., Balakrishnan H. and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", RFC3042, January
2001.
[RFC3074] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load
Balancing Algorithm", RFC3074, February 2001.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC3124, June 2001.
6.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC2246, January 1999.
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC2409, November 1998.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC2607, June 1999.
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion
Window Validation", RFC2861, June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC2865,
June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC2975, June 2000.
[RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC3390, October 2002.
[Congest] Jacobson, V., "Congestion Avoidance and Control", Computer
Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[Paxson] Paxson, V., "Measurement and Analysis of End-to-End
Internet Dynamics", Ph.D. Thesis, Computer Science
Division, University of California, Berkeley, April 1997.
Appendix A - Detailed Watchdog Algorithm
In this Appendix, the memory control structure that contains all
information regarding a specific peer is referred to as a Peer
Control Block, or PCB. The PCB contains the following fields:
Status:
OKAY: The connection is up
SUSPECT: Failover has been initiated on the connection.
DOWN: Connection has been closed.
REOPEN: Attempting to reopen a closed connection
INITIAL: The initial state of the pcb when it is first created.
The pcb has never been opened.
Variables:
Pending: Set to TRUE if there is an outstanding unanswered
watchdog request
Tw: Watchdog timer value
NumDWA: Number of DWAs received during REOPEN
Tw is the watchdog timer, measured in seconds. Every second, Tw is
decremented. When it reaches 0, the OnTimerElapsed event (see below)
is invoked. Pseudo-code for the algorithm is included on the
following pages.
SetWatchdog()
{
/*
SetWatchdog() is called whenever it is necessary
to reset the watchdog timer Tw. The value of the
watchdog timer is calculated based on the default
initial value TWINIT and a jitter ranging from
-2 to 2 seconds. The default for TWINIT is 30 seconds,
and MUST NOT be set lower than 6 seconds.
*/
Tw=TWINIT -2.0 + 4.0 * random() ;
SetTimer(Tw) ;
return ;
}
/*
OnReceive() is called whenever a message
is received from the peer. This message MAY
be a request or an answer, and can include
DWR and DWA messages. Pending is assumed to
be a global variable.
*/
OnReceive(pcb, msgType)
{
if (msgType == DWA) {
Pending = FALSE;
}
switch (pcb->Status){
case OKAY:
SetWatchdog();
break;
case SUSPECT:
pcb->Status = OKAY;
Failback(pcb);
SetWatchdog();
break;
case REOPEN:
if (msgType == DWA) {
NumDWA++;
if (NumDWA == 3) {
pcb->status = OKAY;
Failback();
}
} else {
Throwaway(received packet);
}
break;
case INITIAL:
case DOWN:
Throwaway(received packet);
break;
default:
Error("Shouldn't be here!");
break;
}
}
/*
OnTimerElapsed() is called whenever Tw reaches zero (0).
*/
OnTimerElapsed(pcb)
{
switch (pcb->status){
case OKAY:
if (!Pending) {
SendWatchdog(pcb);
SetWatchdog();
Pending = TRUE;
break;
}
pcb->status = SUSPECT;
FailOver(pcb);
SetWatchdog();
break ;
case SUSPECT:
pcb->status = DOWN;
CloseConnection(pcb);
SetWatchdog();
break;
case INITIAL:
case DOWN:
AttemptOpen(pcb);
SetWatchdog();
break;
case REOPEN:
if (!Pending) {
SendWatchdog(pbc);
SetWatchdog();
Pending = TRUE;
break;
}
if (NumDWA < 0) {
pcb->status = DOWN;
CloseConnection(pcb);
} else {
NumDWA = -1;
}
SetWatchdog();
break;
default:
error("Shouldn't be here!);
break;
}
}
/*
OnConnectionUp() is called whenever a connection comes up
*/
OnConnectionUp(pcb)
{
switch (pcb->status){
case INITIAL:
pcb->status = OKAY;
SetWatchdog();
break;
case DOWN:
pcb->status = REOPEN;
NumDWA = 0;
SendWatchdog(pcb);
SetWatchdog();
Pending = TRUE;
break;
default:
error("Shouldn't be here!);
break;
}
}
/*
OnConnectionDown() is called whenever a connection goes down
*/
OnConnectionDown(pcb)
{
pcb->status = DOWN;
CloseConnection();
switch (pcb->status){
case OKAY:
Failover(pcb);
SetWatchdog();
break;
case SUSPECT:
case REOPEN:
SetWatchdog();
break;
default:
error("Shouldn't be here!);
break;
}
}
/* Here is the state machine equivalent to the above code:
STATE Event Actions New State
===== ------ ------- ----------
OKAY Receive DWA Pending = FALSE
SetWatchdog() OKAY
OKAY Receive non-DWA SetWatchdog() OKAY
SUSPECT Receive DWA Pending = FALSE
Failback()
SetWatchdog() OKAY
SUSPECT Receive non-DWA Failback()
SetWatchdog() OKAY
REOPEN Receive DWA & Pending = FALSE
NumDWA == 2 NumDWA++
Failback() OKAY
REOPEN Receive DWA & Pending = FALSE
NumDWA < 2 NumDWA++ REOPEN
STATE Event Actions New State
===== ------ ------- ----------
REOPEN Receive non-DWA Throwaway() REOPEN
INITIAL Receive DWA Pending = FALSE
Throwaway() INITIAL
INITIAL Receive non-DWA Throwaway() INITIAL
DOWN Receive DWA Pending = FALSE
Throwaway() DOWN
DOWN Receive non-DWA Throwaway() DOWN
OKAY Timer expires & SendWatchdog()
!Pending SetWatchdog()
Pending = TRUE OKAY
OKAY Timer expires & Failover()
Pending SetWatchdog() SUSPECT
SUSPECT Timer expires CloseConnection()
SetWatchdog() DOWN
INITIAL Timer expires AttemptOpen()
SetWatchdog() INITIAL
DOWN Timer expires AttemptOpen()
SetWatchdog() DOWN
REOPEN Timer expires & SendWatchdog()
!Pending SetWatchdog()
Pending = TRUE REOPEN
REOPEN Timer expires & CloseConnection()
Pending & SetWatchdog()
NumDWA < 0 DOWN
REOPEN Timer expires & NumDWA = -1
Pending & SetWatchdog()
NumDWA >= 0 REOPEN
INITIAL Connection up SetWatchdog() OKAY
DOWN Connection up NumDWA = 0
SendWatchdog()
SetWatchdog()
Pending = TRUE REOPEN
OKAY Connection down CloseConnection()
Failover()
SetWatchdog() DOWN
SUSPECT Connection down CloseConnection()
SetWatchdog() DOWN
REOPEN Connection down CloseConnection()
SetWatchdog() DOWN
*/
Appendix B - AAA Agents
As described in [RFC2865] and [RFC2607], AAA agents have become
popular in order to support services such as roaming and shared use
networks. Such agents are used both for
authentication/authorization, as well as accounting [RFC2975].
AAA agents include:
Relays
Proxies
Re-directs
Store and Forward proxies
Transport layer proxies
The transport layer behavior of each of these agents is described
below.
B.1 Relays and Proxies
While the application-layer behavior of relays and proxies are
different, at the transport layer the behavior is similar. In both
cases, two connections are established: one from the AAA client (NAS)
to the relay/proxy, and another from the relay/proxy to the AAA
server. The relay/proxy does not respond to a client request until
it receives a response from the server. Since the two connections
are de-coupled, the end-to-end conversation between the client and
server may not self clock.
Since AAA transport is typically application-driven, there is
frequently not enough traffic to enable ACK piggybacking. As a
result, the Nagle algorithm is rarely triggered, and delayed ACKs may
comprise nearly half the traffic. Thus AAA protocols running over
reliable transport will see packet traffic nearly double that
experienced with UDP transport. Since ACK parameters (such as the
value of the delayed ACK timer) are typically fixed by the TCP
implementation and are not tunable by the application, there is
little that can be done about this.
A typical trace of a conversation between a NAS, proxy and server is
shown below:
Time NAS Relay/Proxy Server
------ --- ----------- ------
0 Request
------->
OTTnp + Tpr Request
------->
OTTnp + TdA Delayed ACK
<-------
OTTnp + OTTps + Reply/ACK
Tpr + Tsr <-------
OTTnp + OTTps +
Tpr + Tsr + Reply
OTTsp + TpR <-------
OTTnp + OTTps +
Tpr + Tsr + Delayed ACK
OTTsp + TdA ------->
OTTnp + OTTps +
OTTsp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TdA ------->
Key
---
OTT = One-way Trip Time
OTTnp = One-way trip time (NAS to Relay/Proxy)
OTTpn = One-way trip time (Relay/Proxy to NAS)
OTTps = One-way trip time (Relay/Proxy to Server)
OTTsp = One-way trip time (Server to Relay/Proxy)
TdA = Delayed ACK timer
Tpr = Relay/Proxy request processing time
TpR = Relay/Proxy reply processing time
Tsr = Server request processing time
At time 0, the NAS sends a request to the relay/proxy. Ignoring the
serialization time, the request arrives at the relay/proxy at time
OTTnp, and the relay/proxy takes an additional Tpr in order to
forward the request toward the home server. At time TdA after
receiving the request, the relay/proxy sends a delayed ACK. The
delayed ACK is sent, rather than being piggybacked on the reply, as
long as TdA < OTTps + OTTsp + Tpr + Tsr + TpR.
Typically Tpr < TdA, so that the delayed ACK is sent after the
relay/proxy forwards the request toward the server, but before the
relay/proxy receives the reply from the server. However, depending
on the TCP implementation on the relay/proxy and when the request is
received, it is also possible for the delayed ACK to be sent prior to
forwarding the request.
At time OTTnp + OTTps + Tpr, the server receives the request, and Tsr
later, it generates the reply. Where Tsr < TdA, the reply will
contain a piggybacked ACK. However, depending on the server
responsiveness and TCP implementation, the ACK and reply may be sent
separately. This can occur, for example, where a slow database or
storage system must be accessed prior to sending the reply.
At time OTTnp + OTTps + OTTsp + Tpr + Tsr the reply/ACK reaches the
relay/proxy, which then takes TpR additional time to forward the
reply to the NAS. At TdA after receiving the reply, the relay/proxy
generates a delayed ACK. Typically TpR < TdA so that the delayed ACK
is sent to the server after the relay/proxy forwards the reply to the
NAS. However, depending on the circumstances and the relay/proxy TCP
implementation, the delayed ACK may be sent first.
As with a delayed ACK sent in response to a request, which may be
piggybacked if the reply can be received quickly enough, piggybacking
of the ACK sent in response to a reply from the server is only
possible if additional request traffic is available. However, due to
the high inter-packet spacings in typical AAA scenarios, this is
unlikely unless the AAA protocol supports a reply ACK.
At time OTTnp + OTTps + OTTsp + OTTpn + Tpr + Tsr + TpR the NAS
receives the reply. TdA later, a delayed ACK is generated.
B.2 Re-directs
Re-directs operate by referring a NAS to the AAA server, enabling the
NAS to talk to the AAA server directly. Since a direct transport
connection is established, the end-to-end connection will self-clock.
With re-directs, delayed ACKs are less frequent than with
application-layer proxies since the Re-direct and Server will
typically piggyback replies with ACKs.
The sequence of events is as follows:
Time NAS Re-direct Server
------ --- --------- ------
0 Request
------->
OTTnp + Tpr Redirect/ACK
<-------
OTTnp + Tpr + Request
OTTpn + Tnr ------->
OTTnp + OTTpn +
Tpr + Tsr + Reply/ACK
OTTns <-------
OTTnp + OTTpn +
OTTns + OTTsn +
Tpr + Tsr + Delayed ACK
TdA ------->
Key
---
OTT = One-way Trip Time
OTTnp = One-way trip time (NAS to Re-direct)
OTTpn = One-way trip time (Re-direct to NAS)
OTTns = One-way trip time (NAS to Server)
OTTsn = One-way trip time (Server to NAS)
TdA = Delayed ACK timer
Tpr = Re-direct processing time
Tnr = NAS re-direct processing time
Tsr = Server request processing time
B.3 Store and Forward Proxies
With a store and forward proxy, the proxy may send a reply to the NAS
prior to forwarding the request to the server. While store and
forward proxies are most frequently deployed for accounting
[RFC2975], they also can be used to implement
authentication/authorization policy, as described in [RFC2607].
As noted in [RFC2975], store and forward proxies can have a negative
effect on accounting reliability. By sending a reply to the NAS
without receiving one from the accounting server, store and forward
proxies fool the NAS into thinking that the accounting request had
been accepted by the accounting server when this is not the case. As
a result, the NAS can delete the accounting packet from non-volatile
storage before it has been accepted by the accounting server. That
leaves the proxy responsible for delivering accounting packets. If
the proxy involves moving parts (e.g. a disk drive) while the NAS
does not, overall system reliability can be reduced. As a result,
store and forward proxies SHOULD NOT be used.
The sequence of events is as follows:
Time NAS Proxy Server
------ --- ----- ------
0 Request
------->
OTTnp + TpR Reply/ACK
<-------
OTTnp + Tpr Request
------->
OTTnp + OTTph + Reply/ACK
Tpr + Tsr <-------
OTTnp + OTTph +
Tpr + Tsr + Reply
OTThp + TpR <-------
OTTnp + OTTph +
Tpr + Tsr + Delayed ACK
OTThp + TdA ------->
OTTnp + OTTph +
OTThp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TdA ------->
Key
---
OTT = One-way Trip Time
OTTnp = One-way trip time (NAS to Proxy)
OTTpn = One-way trip time (Proxy to NAS)
OTTph = One-way trip time (Proxy to Home server)
OTThp = One-way trip time (Home Server to Proxy)
TdA = Delayed ACK timer
Tpr = Proxy request processing time
TpR = Proxy reply processing time
Tsr = Server request processing time
B.4 Transport Layer Proxies
In addition to acting as proxies at the application layer, transport
layer proxies forward transport ACKs between the AAA client and
server. This splices together the client-proxy and proxy-server
connections into a single connection that behaves as though it
operates end-to-end, exhibiting self-clocking. However, since
transport proxies operate at the transport layer, they cannot be
implemented purely as applications and they are rarely deployed.
With a transport proxy, the sequence of events is as follows:
Time NAS Proxy Home Server
------ --- ----- -----------
0 Request
------->
OTTnp + Tpr Request
------->
OTTnp + OTTph + Reply/ACK
Tpr + Tsr <-------
OTTnp + OTTph +
Tpr + Tsr + Reply/ACK
OTThp + TpR <-------
OTTnp + OTTph +
OTThp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TdA ------->
OTTnp + OTTph +
OTThp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TpD ------->
Key
---
OTT = One-way Trip Time
OTTnp = One-way trip time (NAS to Proxy)
OTTpn = One-way trip time (Proxy to NAS)
OTTph = One-way trip time (Proxy to Home server)
OTThp = One-way trip time (Home Server to Proxy)
TdA = Delayed ACK timer
Tpr = Proxy request processing time
TpR = Proxy reply processing time
Tsr = Server request processing time
TpD = Proxy delayed ack processing time
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgments
Thanks to Allison Mankin of AT&T, Barney Wolff of Databus, Steve Rich
of Cisco, Randy Bush of AT&T, Bo Landarv of IP Unplugged, Jari Arkko
of Ericsson, and Pat Calhoun of Blackstorm Networks for fruitful
discussions relating to AAA transport.
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Jonathan Wood
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
EMail: jonwood@speakeasy.net
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.