Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(ASCEND) Pool handling strategies (was: IP Addresses needed for 4048)



On Tue, Mar 31, 1998 at 12:04:23PM -0500, Jim Howard wrote:
> At 09:18 1998/03/31 -0500, Phillip Vandry wrote:
> >- If you have more addresses than channels, then even if all your
> >channels are constantly used, addresses get to have a little "rest"
> >between uses. This means that if the previous user logged off
> >uncleanly, possibly leaving some TCP connections open or otherwise
> 
> Does the system actually rotate through the pool like this?
> I had always assumed that it took the first available
> starting at lowest address and working up...

It indeed rotates and IMHO this is a Bad Idea (tm).

1) I want to revert the "unclean shutdown" argument. If a user drops
   his connection with TCP connections still open, these connections
   will live _forever_ - constantly retrying with a new segment every
   minute or two. This is _evil_ when you use dialed connections. If
   an IP would be reused fast, the dangling TCP connection would be
   RSTed by the new target soon. The dangling TCP lives as long as
   the IP is _not_ reused.

2) Rotation is extremly user-unfriendly. It prevents dial-on-demand
   setups completely, because everytime I connect I get another IP
   and all my still open TCP connections are dangling. This as well
   prevents NAT from beeing of much use when combined with dial on demand
   and a pool dialup.

3) A user could try to grab the old IP by just trying to IPCP for it.
   This is successfully prevented by Pool Only=Yes. And we all know
   that we don't want to mess around with Pool Only=No, don't we ?

My thinking about this (likely not Ascends - bad enough):

1) Pool IPs should be handed out with a "try-my-best-to-reget-the-old-IP"
   strategy. If the IP cannot be reused or the NAS has no information
   any longer about which profile did have which IP a hour ago, it should
   be LRU - but only then.

2) Pool Only needs another mode, lets call it "Relaxed". It means that
   it allows the user to get an IP of his choice as long as this IP is
   in the pool specified by the user profile and is not currently in
   use (obviously). This would allow the user to reget his old IP if
   at all possible even when the NAS has forgotten about it.

Do we want to vote about this ? It probably requires a FR (dunno why
fixing things to behave in a common sense way is often called FR at
Ascend ;) - do we make one ?

The IANA subsidiaries (InterNIC, RIPE, APNIC etc) who allocate the
address space would likely jump into your face with their naked ass
if you try to request addresses for static assignement to dialups,
telling them "uhh my NAS cannot handle this smart so we need static
IPs" is probably answered with "then get another NAS". Under this
conditions (getting more stringent every day) a "smart" pool allo-
cation strategy is really needed in the Max family.

-- 

Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4

+-o-+--------------------------------------------------------+-o-+
| o |               \\\- Brain Inside -///                   | o |
| o |                   ^^^^^^^^^^^^^^                       | o |
| o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>


Follow-Ups: References: