Hi, Stefan,
Fragmentation issues have been a focus of both the INT and TSV areas.
It'd be useful to contact the ADs directly for feedback in both cases.
I suspect the best place to start would be the TSVDIR, though. In the
past, I've been the 'stuckee' for some of the fragmentation-related
reviews, FWIW, so here are my initial observations:
- the document should more clearly distinguish between the limiting
sizes of messages at different layers in the stack
Although RADIUS uses the term "packet" even for RADIUS-level
data (RFC 2965), I'll use the following terms:
message - a RADIUS unit of data
packet - a UDP unit
datagram - an IP unit
i.e., a single RADIUS message (up to 4096 bytes) is always
sent in a single UDP packet, which may be sent over one or more
IP datagrams. Thus RADIUS already relies (heavily, IMO) on
IP-level fragmentation and reassembly.
E.g., RADIUS specifies a max length of 4096 octets;
the field supports the same length as a max IP
datagram (65535). The largest IPv4 datagram that is guaranteed
to be reassembled is 576 bytes. So RADIUS is already
potentially sending UDP packets that can't be reassembled
by IPv4. There's nothing I see in RADIUS that reacts to
path MTU or even interface MTU.
- the need to send "large amounts" of data should be better discussed
Even the 100K data limit can generate an excessive
burst if the network is congested. See RFC 5405.
However, given the stop-and-go (windowsize =1) protocol
of exchanging fragments one at a time, this probably isn't
an issue - but it should be explained as such.
- PMTUD is a red-herring unless RADIUS sets the DF bit
That would be a bad idea, IMO, because RADIUS already
allows message sizes in excess of the largest safely
assumed MTU. There's no good reason to set DF=1
for RADIUS packets - they're not sent at a high enough
data rate to have problems with IPv4 ID uniqueness
(see RFC 6864).
However, RADIUS doesn't appear to set the DF bit,
nor is that discussed in this doc, so this is a
red herring.
- nothing in RADIUS appears to avoid IP fragmentation per se
So I don't see why that's being added here.
I hope that helps... I'd be glad to address further questions on this list.
Joe
On 6/5/2014 6:35 AM, Stefan Winter wrote:
Hello tsv-area,
I'm co-chair of radext and the document shepherd for the above document,
and it's currently awaiting its PROTO write-up.
As I went through the latest revision, it occured to me that there are
quite some transport considerations in this, which are beyond my
technical knowledge.
In short:
A protocol that previously had no fragmentation support (RADIUS over
UDP, max size 4096 per datagram, max one datagram in flight, may be
"routed" via RADIUS proxies in a kind of overlay network) now gets some;
the fragmentation is done in a way which is "far away" from the usual
way - no sequence numbers, duplicate detection is based on a randomly
chosen State attribute, there is no explicit NAK for missing chunks and
instead the RADIUS timeout is the only way to detect and correct
fragments gone AWOL. There may be fragmentation-aware and -unaware
RADIUS proxies on the path between sender and ultimate recipient of the
payload.
I'm thinking that this warrants a closer look by TSV experts. Am I
asking at the right place?
The draft is here:
https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
Greetings,
Stefan Winter
