Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Pool handling strategies (was: IP Addresses needed for 4048)
On Wed, Apr 01, 1998 at 09:49:49AM -0500, Phillip Vandry wrote:
> > 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.
>
> One thing I'm not is a TCP expert, so I may very well be wrong, but
> shouldn't the sender TCP react to the ICMP Host Unreachable messages
> it's going to receive in response to anything it tries to send, thus
> terminating the connection just as effectively as an RST would?
Generally, not. Most relevant to this has already been said, I wont
repeat it. One _could_ eventually implement a TCP shutdown if for a
remarkable time no segment was answered but most of them got an ICMP
destination host unreachable message (host, not net for that matter),
but this timeout should be large (say 2 hours as an _absolute minimum_),
so it doesn't really help here. It is a basic property of TCP that it
has no immanent timeouts and is thus never terminated just by failures
of lower layers, it requires a TCP layer interaction (RST) or an ex-
plicite application layer request to accept termination.
Again, I didn't want to discuss this into depth here, just notice that
the current "round robin" strategy for sure does not prevent dangling
TCP conns but indeed maximizes their lifetime. So if TCP would be an
arguement to any allocation strategy it probably is one against LRU ;)
> > 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.
>
> I put exactly this into the old Max feature request box on the web site
> about a year ago. You don't see it yet, do you? :-(
Nope - BTW I talked to Ascend people about the idea of a "FR voting page"
on their WWW where you can see which FRs are currently in discussion
and could vote pro or con, eventually with a sentence or two describing
your decisison. This would make the FR process much more effective. But
this never happened, either - more than a year. Instead the "would you
want to pay for the feature" checkbox appeared on the WWW form...
> > 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.
>
> Sounds like a good extention of the previous.
Your word into Ascends aural receptor (modified german proverb).
--
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>
References: