Re: [radext] A proposal to allow more than 256 packets on any connection

Alan DeKok <> Tue, 25 April 2017 06:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9347C127286 for <>; Mon, 24 Apr 2017 23:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jRnxQbW2sn85 for <>; Mon, 24 Apr 2017 23:01:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 91624127337 for <>; Mon, 24 Apr 2017 23:01:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F20CA91D; Tue, 25 Apr 2017 06:01:08 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6XXA_D9_XngL; Tue, 25 Apr 2017 06:01:08 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 6A902535; Tue, 25 Apr 2017 06:01:08 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_99D8C3F6-73AE-4231-A5EE-5FC8CB0AE8D0"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail
From: Alan DeKok <>
In-Reply-To: <alpine.WNT.>
Date: Tue, 25 Apr 2017 02:01:06 -0400
Message-Id: <>
References: <> <> <> <> <> <> <> <alpine.WNT.>
To: Peter Deacon <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [radext] A proposal to allow more than 256 packets on any connection
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Apr 2017 06:01:12 -0000

On Apr 24, 2017, at 9:49 PM, Peter Deacon <> wrote:
> On Mon, 24 Apr 2017, Ignacio Goyret wrote:
>> The best solution still remains that if you need more than 255 pending
>> requests, use another UDP port. And if you ran out of UDP ports, use
>> another IP address.
>> These are much simpler solutions than any other proposal so far.
> Completely agree.  Useful to look at the numbers.
> Assume a single src/dst IP with pool of 1000 src ports and an average round trip time of 100 ms.  This translates to 256,000 concurrently "in-flight" requests or 2,560,000 RADIUS requests+responses per second.
> Who pushes anything approaching this from aclient?

  Not many systems.

  However... one problem with UDP is the ability to fill a network with data.  Networks are bounded both by per packet rates, and by total throughput.  RADIUS packets are small enough that they hit the network limit on packets, long before they hit the limit on total throughput.

  This is mainly due to having small packets, and using UDP transport.

  You could use TCP to avoid the problem of "one RADIUS packet == one ethernet frame".  But RADIUS allows only 256 packets outstanding at a time.  So if the packets are proxied, each TCP connection can only have <100K of data sent before the client MUST open another source port.  Which again runs into the ethernet frame limit.

  Allowing many RADIUS packets over one TCP connection means that you can fill a network with RADIUS traffic.  This is just impossible with RADIUS as it exists today.

>  What specifically is your request/response rate per second and total number of concurrently outstanding requests from your clients?  I would love to see actual figures justifying change rather than blanket assertions which for all anyone knows could well be entirely explained away by known or unknown implementation problems.

  One word: proxying.

  Once a packet is proxied, the clients can see request / response time frames of 100s of milliseconds, or even seconds  That puts a much stronger pressure on the number of packets outstanding.

> Those using TCP and DTLS transports have a much better case.  No doubt ID space is more inconvenient here leading to many times more TCP/TLS connections than optimal.
> With TCP there are inherent limits associated with too many requests dependent on a single head-of-line blocked stream.  You don't want thousands of realtime authentication requests piling up generally or simultaneously delayed by single events (e.g. tail loss)

  The need for many RADIUS packets is largely driven by accounting traffic, not authentication traffic.

  And TCP "head of line" blocking only affects the network side of the transport.  If the packets actually make it to the RADIUS server, it is free to respond to the packets in any order it choses.

  Another counter-argument to TCP "head of line" blocking is that it's 2017.  The internet is large and fast.  People download gigabytes of traffic daily, and are minimally affected by packet loss.  I think it's reasonable to assume that packet loss won't affect RADIUS over TCP much, either.

> Is it unreasonable to expect a system acting as a RADIUS client for what must be millions of concurrent users to not be resource limited by something as trivial as number of available source ports or lack a scalable mechanism to listen concurrently across them?  Speaking for myself while clearly inconvenient the answer is no.

  That's a reasonable argument.  I'm not even disagreeing with it much.

  My draft is an attempt to address the stated need for allowing more outstanding RADIUS packets on one UDP or TCP connection.  There have been multiple suggestions for a solution to the problem, most of which involve changing the RADIUS header.  As I've pointed out, I think such changes will be rejected not only by RADEXT, but by the wider IETF reviewers.

  My draft is an attempt to address both the technical requirements, and the wider review.  There's no question that it will work.  The questions are whether it's needed, and whether it will achieve larger consensus that the solution is a reasonable one.

  Alan DeKok.