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

Internet Message Format | 1992-12-27 | 9.6 KB

Path: sparky!uunet!gossip.pyramid.com!olivea!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!unidui!Germany.EU.net!mcsun!inesc.inesc.pt!freya.inesc.pt!werner
From: [e-mail] (Werner Vogels)
Newsgroups: comp.sys.isis
Subject: Re: Forwarded comments Re: Notes on IP Multicast option for ISIS
Message-ID: <[e-mail]>
Date: 27 Dec 92 13:11:52 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: INESC - Instituto de Engenharia de Sistemas e Computadores, Lisboa, Portugal
Lines: 172
Nntp-Posting-Host: freya.inesc.pt


|> This is very interesting.  If altrnatives to mrouted surface, I hope people
|> will keep us informed!  As it happens, Isis depends only very slightly on
|> routing and certainly doesn't count on the membership information in any
|> significant way (except that you obviously won't get a speedup until the
|> add-member information propagates enough so that packets are forwarded, if
|> necessary, to a new member!)

There is a performance cost (more retries) if you start sending immediately
after you have joined, and the other members are further away. The same for
the build up of the tables after a crash, eventually the tables will be
correct but it may cause stations on a connected link to consider the other
stations down, or partitioned. The failure detection modules should cover
this correctly but it triggers some overhead.

It would be nicer to be able to rely on your router to have correct
information about other connected links, you wouldn't have to go over to
the link to make sure you router's information isn't out of date. It has
to do with the fact that you keep membership information at two levels:
ISIS and mcastip, where the latter is of no use to the first.

|> As for the TTL, I currently use TTL_SITE, but you could reconfigure the
|> code to change this.  Should it be an option?

If you are not connected to the mbone, the ttl is only important if you
have setup routing between subnets in your organization. The metrics on
the links define how far you message will travel within your organization.
Of course this also depends on your network topology.

|>  Should it be an option?

If you only use mcastip as a generic mechanism and can be sure that there
will be no conflicts with other users of mcastip you shouldn't worry about
the scope. But if more users (other software packages) use mcastip you
should be careful with choosing your ttl so you can limit the resources
used.


|> >With port do you mean UDP port or mcastip ip address?
|>
|> Both.  The way that Steve Deering's code works, an ipmcast address is
|> associated with one or more ports, which have normal UDP port numbers.
|> The port number on the incoming mcast packet is used to decide who  gets
|> a copy among those who added themselves to the IP multicast group.
|> So, for an Isis group, you would ideally want to have a port per group
|> as well as an IP multicast address per group.  If you have less, say one
|> port for everyone, there is no choice but to re-use port numbers (hence
|> we use SO_REUSADDR) and this means that processes will get ipmcasts sent to
|> groups other than the one they belong in some cases -- specifically, when
|> two groups with the same port number are used on the same machine...

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.

|>
|> Anyhow, this is all hidden from users.  It has performance implications
|> but normally they won't be major ones...  The number of ports available
|> is a compile time system parameter for Isis itself.

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

|> >Personally I think you should have a second selection mechanism so you can
|> >still use mcastip (and hw multicast) to be used in other then diffusion mode.
|>
|> I think you may not be aware of what diffusion mode means in Isis, since
|> this remark confuses me.

indeed, I should have read the manual instead of relying on my intuition.

|> >We have more applications running (conferencing, etc) that use mcastip, so we
|> >can never be sure that the complete address space at the controller is to be
|> >allocated to the group communication module.
|>
|> 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. Especially those interested in anonymous
group membership. I have already seen several servers (naming, printers,
etc) that use mcastip for fault-tolerance or location transparency. The
current ipmcast implementation will have to change to support a larger
number of users, but this effort will have to be done by the vendors, the
implementation used now was not meant to be used at this scale. But the
current work on SIP and PIP is more promising, so that it would be wise
not to consider ipmcast as the standard for the future, but to wait for
the transition to a more capable new ip protocol.


The use of the number of mcastip addresses is defined by the station
that has the least number available. Often we use dedicated machines as
server, so that the usable address space get defined by these machines.
If you have several servers running at these machines, and they all use some
sort of multicast based communication it becomes the bottleneck for
address assignment.

It is not only mcastip that uses hardware mcast but other protocols we
run like XTP also take their share of addresses away. So that the number
of addresses available can never be determined on forehand.

|> >Personally and also from experiments: if you only use mcastip on a local area
|> >network you are better off making your own interface to the network and
|> >multicast addresses, with more and more machines providing the BSD packet
|> >filter you can reasonably standardize this as well. You will get a better
|> >performance as soon as there is more then one receipient. The nit on SunOS is
|> >*bad*: do not use it if you have very performance critical applications.
|>
|> Perhaps I should add that as an option?  Obviously, for the near term,
|> the standards argument says that Isis has to work for the vendor provided
|> and supported technology.  It isn't my fault if the standard could be
|> improved!

Sorry, my remarks should be seen as a general statement, for ISIS that is
concerned with the use of standard protocols different rules need to be
applied. Of course if new technology becomes available at this level, use
it! But the current implementation of the "standard" will still need a lot
of work before we can use it with a broader scope. (Personally I think
we should be cautious and wait for the new IP protocols to arrive).

|> >The router we are to develop bases its interrouter communication on reliable
|> >group comm methods making it easier to maintain shared state etc and restoring
|> >the state will become much more efficient, etc.
|>
|> Sounds like we will want to support the INESC router when you do make it
|> available!  Let us know...

The routers developed at INESC are part of a project that wants to expand
our LAN oriented protocols to extended LAN's and MAN's, trying to maintain
the high performance and guarantees of bounded execution time, etc. The
new protocol suite that will arise from the efforts in the NAVIGATORS
project will eventually incorporate these solutions for internetworking.

In principle these routers have nothing to do with mcastip. Mcastip is
dedicated towards anonymous membership, and provides no guarantees, for
this you need a scheme where the routers forward the message to subnets
that have stations, that are possible interested in the messages transmitted
at this address. This to support a possible worldwide distribution of
multicast messages.

In our interconnection work we focus on different schemes. One of the first
issues is that, in the case of reliable group communication with certain
order guarantees as we have been building, you can not deal with
anonymous member behavior very well. So if you build group communication
for a MAN environment you will need some knowledge about where possible
members of your group can be located. We will develop our material based
on the assumptions that we can limit our internetwork communication to
an administrative domain with a known network topology. In this case
the limited number of routers/gateways and name/directory servers can
provide knowledge about group members that is correct and consistent.
A number of interesting opportunities arise with regard to group scope,
local use of hw-addressing and proxy or delegated execution of LAN oriented
protocols.

Another issue is that I do not like the large state tables that are
kept at routers. If you have a high speed, high bandwidth backbone
you want to profit from this technology, you do not want to spend
much time in table lookups, state restore after failure etc. The
switching at the backbone gateway stations needs to be very fast
to profit from its connection to the backbone. We will provide some
solutions for this.

But back to our mcastip problems, I will see if I can hack up a IGMP
router to add some more reliability for the case of a single a-domain.
I will let people know if I succeed. To fully profit from the high
performance interconnected group communication you will have to wait
for the full release from INESC (in corporation with and compatible
with .... ).

--
Werner