Subject: [radext] New Draft for RADIUS Message Bundling

From: <[email-masked]>
Date: Mon, 10 Aug 2015 15:47:11 +0530

Hi All,

Sorry for the earlier Mail with "*Dell - Internal Use - Confidential *" .  Removed it  and reposting it again.

We have proposed a new draft for RADIUS Message Bundling.

Name:                  draft-aravind-radext-message-bundling

Revision:              00

Title:                      RADIUS Message Bundling

Document date:               2015-08-04

Group:                  Individual Submission

Pages:                   5

URL:            https://www.ietf.org/internet-drafts/draft-aravind-radext-message-bundling-00.txt

Status:         https://datatracker.ietf.org/doc/draft-aravind-radext-message-bundling/

Htmlized:       https://tools.ietf.org/html/draft-aravind-radext-message-bundling-00

Abstract:

   This draft proposes a mechanism to bundle multiple RADIUS requests in

   a single RADIUS Message which could assist in improving the overall

   performance and scalability.

We would love to hear your reviews and comments.

Thanks,
S. Aravind Prasad

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Aug 2015 10:57:00 -0400

The RADIUS community already has a specification for running RADIUS over
TCP/TLS; see RFC 6613.

Have you evaluated that specification for your use cases?

I think that TCP can provide good bundling of requests, and unlike a
RADIUS specific solution is likely to have better transport
characteristics.

If TCP can work for your use case, I'd recommend exploring that.  If
not, I'd recommend explaining the problems with TCP in your target
environment.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2015 09:41:24 +0200

I agree with Sam here.  I've had discussions for ~3 years with various people about putting multiple RADIUS packets into a UDP packet.  In the end, it just solves one problem: more packets to the RADIUS server.

  It compounds another problem: port / ID limitations.  RADIUS has an 8-bit ID, which you run into *very* quickly in high load situations.

  Even if this proposal would be standardized, the ID limitation problem would mean that this proposal has minimal benefits.

  If we solve the RADIUS ID limitation, then we might as well just use TCP for everything, which avoids UDP / PMTU limitations.  And which makes this proposal unnecessary.

On Aug 10, 2015, at 4:57 PM, Sam Hartman <[email-masked]> wrote:

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: <[email-masked]>
Date: Sun, 16 Aug 2015 04:22:35 +0530

Dell - Internal Use - Confidential

Hi Alan/Sam,

Thanks a lot for reviewing the draft and providing your comments.

Hi Sam,
Actually, even in RADIUS over TCP, each RADIUS Message can hold only one RADIUS request. TCP will take care of message delivery but still the RADIUS Messages can't hold multiple requests currently.
The proposed idea is to bundle multiple RADIUS requests in a single message. No changes are made to individual RADIUS requests. Hence, this will help to improve network bandwidth usage and possibly performance.

Hi Alan,
Yes, this draft will not solve the ID problem. It only proposes a way to bundle multiple requests in a single RADIUS Message.
But, as discussed above, the usage of TCP may not solve the bundling problem. Hence, this proposal is actually applicable to both TCP and UDP.

Thanks again for reviewing the Draft and kindly let us know your views and comments.

Thanks,
S. Aravind Prasad

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Wednesday, August 12, 2015 1:11 PM
To: Sam Hartman
Cc: Sridharan, Aravind; [email-masked]; Sivarama, Sanal Kumar; [email-masked]
Subject: Re: [radext] New Draft for RADIUS Message Bundling

On Aug 10, 2015, at 4:57 PM, Sam Hartman wrote:

> The RADIUS community already has a specification for running RADIUS
> over TCP/TLS; see RFC 6613.
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Aug 2015 10:25:45 -0400

>>>>>   <[email-masked]> writes:

    >    Actually, even in RADIUS over TCP, each RADIUS Message can hold
    > only one RADIUS request. TCP will take care of message delivery
    > but still the RADIUS Messages can€™t hold multiple
    > requests currently.

    >    The proposed idea is to bundle multiple RADIUS requests in a
    > single message. No changes are made to individual RADIUS
    > requests. Hence, this will help to improve network bandwidth usage
    > and possibly performance.

I can understand an argument that you run into a problem with a large
number of packets generated with a lot of requests at once.
However, TCP will help with that by allowing multiple requests to be in
a single network packet.

Am I correct in my understanding that if your TCP implementation is
efficient about filling packets, the difference in these proposals is
that:

* in TCP a request can span multiple packets.  That is, say the packet
  has not quite enough space for the final request in the packet.

* The overhead/bookkeeping between the two proposals would be different
  in terms  of overhead bytes in a packet.

So, for the multiple requests proposal to be a advantage, its
bookkeeping/overhead would need to be sufficiently better than TCP to
justify better bandwidth utilization.

Have I got that right?

If so, can you help explain how that actually works out to be the case?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 17 Aug 2015 22:33:40 +0200

> However, TCP will help with that by allowing multiple requests to be in

  I agree.  I see no reason to do packet bundling on TCP.

  Alan DeKok.

---

From: <[email-masked]>
Date: Thu, 20 Aug 2015 09:47:23 +0530

Hi Sam,

Thanks a lot again for your review comments.

Yes, agree with you. Finally it comes down to the following:

1)      Without bundling (in case of individual packets), there is the overhead of adding TCP and Ethernet headers to individual RADIUS packets sent to server.

2)      With Bundling, the overhead of TCP and Ethernet Header additions are avoided. Instead, now it’s the overhead of bookkeeping and bundling multiple RADIUS requests in the single message.

As such, it’s a kind of trade off now ☺. We will work on this further and will provide the updates after we come up with some optimizations.

Thanks a lot again for spending your valuable time reviewing our draft and providing your comments ☺.

Thanks,
S. Aravind Prasad

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Monday, August 17, 2015 7:56 PM
To: Sridharan, Aravind
Cc: [email-masked]; [email-masked]; Sivarama, Sanal Kumar; [email-masked]
Subject: Re: [radext] New Draft for RADIUS Message Bundling

>>>>> writes:

> and possibly performance.

I can understand an argument that you run into a problem with a large number of packets generated with a lot of requests at once.
However, TCP will help with that by allowing multiple requests to be in a single network packet.

Am I correct in my understanding that if your TCP implementation is efficient about filling packets, the difference in these proposals is
that:

So, for the multiple requests proposal to be a advantage, its bookkeeping/overhead would need to be sufficiently better than TCP to justify better bandwidth utilization.

Have I got that right?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Aug 2015 06:04:36 -0400

>     Hi Sam, Thanks a lot again for your review comments.

    >    1) Without bundling (in case of individual packets), there is
    > the overhead of adding TCP and Ethernet headers to individual
    > RADIUS packets sent to server.

    >    2) With Bundling, the overhead of TCP and Ethernet Header
    > additions are avoided. Instead, now it€™s the overhead
    > of bookkeeping and bundling multiple RADIUS requests in the single
    > message.

Except that even without bundling TCP will stick more than one RADIUS
message in a single packet.
Let's say that your radius messages are 150 bytes or so, and you can get
9 of them into a TCP packet.
So, the TCP and ethernet headers are amortized over 9 messages without
your proposal.

Let's say that you somehow save enough space that you can get a 10th
request into the packet.  That would be doing fairly good in my opinion
for your proposal.  Even if you could do that well, I don't understand
how it's worth standardizing.

It seems like you get a vast majority of the benefits simply from
putting more than one RADIUS message into a single TCP packet, and we
get that today.