RE: DISCUSS: draft-ietf-radext-fixes

["David B. Nelson" <d.b.nelson@comcast.net>]

Barney Wolff writes...

> In other words, I don't see how the server can avoid keeping a cache
> of requests/responses, so I don't see what requiring monotonicity can
> gain.

I was expounding on what I thought the posters had in mind rather than
vouching for the validity of the assertions, so maybe I've added some
confusion to the discussion.  If so, I'm sorry.

If you allow for UDP datagrams to go missing, which is a required assumption
in the general case, the server does need to cache some reasonable number of
recently used Identifier values.  If the client always sends monotonically
increasing values, the size of the required cache is fairly small.  If the
Identifier value can be random, then you might well need to cache 256 values
for each NAS IP/UDP Src Port tuple.

I didn't follow the discussion (referred to earlier in this thread) about
the need to cache the entire request message, so I'll not comment on that.

It might be that Glen is optimizing for a class of well behaved LANs in
which dropped datagrams and out of order deliver rarely if ever occur.  I
agree that the concept of the server performs duplicate detection by keeping
only the last received Identifier value, in a monotonically increasing
sequence, works only when the network provides reliable, in-order packet
delivery, e.g. what you might expect with TCP.




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>