Subject: [eap] Discussion: Retransmission Issues

From: [email-masked] (Bernard Aboba)
Date: Wed, 21 May 2003 15:00:58 -0700 (PDT)

One issue that has been coming up lately surrounding EAP is retransmission
behavior.  This includes:

a) EAP authenticator retransmission algorithms
b) 802.1X supplicant retry algorithms
c) RADIUS client retransmission algorithms

If any of these algorithms is too aggressive, the result can be excessive
load, queueing delays and high packet loss.

To fix this, it is important to introduce the concept of exponential
backoff to EAP, 802.1X and RADIUS.  We've had a discussion with respect to
EAP and RADIUS transport behavior in the context of Issue 125 on the EAP
issues list (http://www.drizzle.com/~aboba/EAP/eapissues.html).

Let me try to outline how I think we can fix this.

The TCP retransmission algorithms outlined in RFC 2988 form a good basis
for a proposal, but as Glen Zorn has pointed out, RFC 2988 is inapplicable
in places and is also incomplete (e.g. no jittering). That means that
merely citing RFC 2988 is insufficient; more detail is required.

A reasonable start is to recommend dynamic RTO estimation, using
RTOmin=1 second, RTOinitial=3 seconds, and RTOmax=60 seconds. For the
RADIUS client, the suggestion has been to increase RTOinitial to 5 seconds
(Glen Zorn). The RTO value is backed off exponentially (doubled) on
retransmission, and a moving average estimator is used, as specified in
RFC 2988.  One issue is whether the timer granularity in RFC 2988 is
appropriate or not.  In order to provide jitter, the actual RTO value is
chosen randomly on the interval [max(0, RTO - 200 ms), RTO + 200 ms].

Note that although RFC 2865 warns that TCP-based retransmission may be too
aggressive, we have seen cases of RADIUS clients with retransmission
algorithms (e.g. 1 second RTO with no backoff) considerably more
aggressive than TCP and this can cause RADIUS server overload.

---

From: [email-masked] (Jari Arkko)
Date: Thu, 22 May 2003 08:13:36 +0300

> RTOmin=1 second, RTOinitial=3 seconds, and RTOmax=60 seconds. For the

Ok, but see below.

> RFC 2988.  One issue is whether the timer granularity in RFC 2988 is

Ok. What is the timer granularity in 2988?

> chosen randomly on the interval [max(0, RTO - 200 ms), RTO + 200 ms].

I would expect e.g. randomness of dial-in clients connecting to provide
some randomness between different EAP sessions. In other words, not all
would retransmit at the same time, if that was the reason why you
wanted to provide jitter. But I'm OK with providing it too, not sure
we can rely on the connection randomnessin in all cases.

> aggressive than TCP and this can cause RADIUS server overload.

Yes.

I'm generally OK with this approach, but I'm wondering what all
this will do to, say for fast movements. In most of the cases you would
see very quick responses, probably in the order of a hundred or few
hundreds of ms. But if a packet is lost an initial RTO of 3
and one retransmission causes a deley of at least 6 seconds. Do
the timers have to have only second granularity and does RTOmin have
to be 1 s?

--Jari