NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/isis/355

Internet Message Format | 1993-01-03 | 3.6 KB

Path: sparky!uunet!stanford.edu!rutgers!rochester!cornell!ken
From: [e-mail] (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Forwarded comments Re: Notes on IP Multicast option for ISIS
Message-ID: <[e-mail]>
Date: 3 Jan 93 19:23:20 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Lines: 62

In article <[e-mail]> [e-mail] (Werner Vogels) writes:
>So you would only re-use ports every n-thousand, but ipmcast address much
>more often. When having a large port range you can have the OS levels
>filter for you if you reuse ipmcast addresses.

Actually, as things stand, I wasn't expecting to re-use ipmcast addresses
at all.  The initial software is simply limited and won't allow you to
use ipmcast if your hardware won't allow the ADDMEMBER function.  And, as
things stand, it would be a good idea to have as many as one port per
mcast address.

I'm requesting a range of addresses from the Inet address people.  I doubt
that I can get more than 512 of them, although the V people have something
like 24 bits and I'll get what I can.

The core issue with ports is that Isis needs a range and we can't easily
prevent UNIX from allocating in that range, especially on systems that do
the "0" port allocation using a randomized scheme (ULTRIX is one).  On these,
people could grab ports Isis technically needs, and the bigger the range
Isis is told to use, the larger the risk.  Practical considerations make
me think that more than 10 or so will be troublesome to manage in big
commercial configurations.

So, you could get a situation with one ipmcast address per group, but
reuse of the port numbers (we take the ipmcast address itself mod N,
where N is the number of ports I am allowed to use, and add this to
a base the user specifies).

The risk is then that program p1 is in group A and p2 is in group B, they
get different ipmcast addresses N apart, hence the port number Isis uses is
the same.  Now, if you run p1 and p2 on the same machine, they get each
other's packets -- they discard them, but they get them just the same...

If we can't use ipmcast, remember, things still work, but the process
in trouble gets everything through the retransmit logic, which has a
hook to "retransmit" instantly if this seems to be the case.  So, you
go point to point, but perhaps not with a big performance penalty.

>[...] we simple fools with only an Academic License will get a predefined
>number, would  there be a way to make this dynamically configurable?

This is a good point.  I should probably make it dynamically configurable
in some reasonable way.

>|> When in my stuff, I have one group (/sys/ipmcast) that handles the allocation
>|> of ipmcast addresses.  But if other applications use it, I will have a problem,
>|> true...
>
>You definitely will, because more and more packages will start using
>ipmcast if it come available....

We'll have to see how this works out.  I am not sure if you are
discussing an issue of importance in commercial settings or in
academic research settings.  If the latter, we can do something sensible
about it.  In the former, its just one of those things that system
administators need to deal with -- they will have to work out how they
want things to work, and as long as Isis can do what they conclude it
should do, the problem is "controlled"...
--
Kenneth P. Birman                              E-mail:  [e-mail]
4105 Upson Hall, Dept. of Computer Science     TEL:     [phone] (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     [phone]