home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / isis / 340 < prev    next >
Encoding:
Text File  |  1992-12-22  |  4.0 KB  |  88 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: Notes on IP Multicast option for ISIS
  5. Message-ID: <1992Dec22.212230.28572@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. Date: Tue, 22 Dec 1992 21:22:30 GMT
  8. Lines: 78
  9.  
  10. I am working on IP multicast for Isis, as readers of this group
  11. are probably aware.  I just want to outline the structure of what
  12. I am doing and solicit feedback or ideas before the design becomes
  13. locked into stone.
  14.  
  15. When will IP mcast be used?
  16.    - I plan to require that all (or most) machines using Isis support
  17.      the IP Multicast standard, which was developed by Steve Deering at
  18.      Stanford and has become part of Solaris 2.1; Steve's code is also
  19.      available for many other platforms, but perhaps not as a standard
  20.      offering from the vendor.
  21.  
  22.      The code defines some setsockopt() options: SO_REUSEADDR, IP_MULTICAST_TTL,
  23.      IP_ADD_MEMBERSHIP, IP_DROP_MEMBERSHIP.  It also includes a multicast
  24.      router, called "mrouted".  If these are not up, IP multicast use triggers
  25.      a point-to-point mechanism slightly but not drastically slower than
  26.      the usual Isis UDP scheme.
  27.  
  28.    - You will need to have an authorization for "ipmcast" in your isis.rc
  29.      file.
  30.  
  31.    - You will need to specify ISIS_IPMCAST as a flag to isis_remote_init()
  32.  
  33.    - The group(s) that will use IP multicast should specify PG_IPMCAST as 
  34.      an option to pg_join() (clients find out automatically).
  35.  
  36.    - You will need to specify a range of port numbers dedicated to use by
  37.      Isis for IP multicast.  You can decide how many and what base address
  38.      Isis should use.  Isis will reserve them as soon as a program specifies
  39.      ISIS_IPMCAST.  Ideally, one port per group using PG_IPMCAST, but we
  40.      can manage if the number is smaller.  In the limit, you can specify that
  41.      just one port be used, but in this case processes will get and discard
  42.      some messages not intended for them.
  43.  
  44.    - Only messages sent in diffusion mode (to the full set of members and
  45.      clients) will be multicast.  However, you can overlap groups and in this
  46.      way can build up other patterns pretty easily.
  47.  
  48. How does it work?
  49.    - We fragment your message into 4k chunks and stick a small (44 byte)
  50.      header on each.  
  51.  
  52.    - For each group joined using PG_IPMCAST as an option, we allocate an IP
  53.      multicast address and register the members and clients.
  54.  
  55.    - Members will multicast a packet initially, then retransmit point to point
  56.      if some processes NACK or fail to ACK it.
  57.  
  58.    - Once received, packets travel the same code path as other Isis packets,
  59.      so all the usual Isis ordering properties and so forth hold.
  60.  
  61. Summary:
  62.    - isis_remote_init(..... ISIS_IPMCAST); to start it up
  63.    - pg_join(.... , PG_IPMCAST, ....); to enable for a group
  64.    - Everything else works as usual, transparently.
  65.  
  66. From experiments (done, however, with a different version of the code) we
  67. expect to see a benefit for groups with more than about 4 members.  However,
  68. we have yet to experiment seriously with the new code on Solaris, for
  69. technical reasons, so I won't have solid numbers for a little longer.
  70. My guess -- just a guess -- is that performance will be fairly flat as
  71. a function of group size until groups+clients gets pretty large, probably
  72. 40 or 50 or more.  By then, acks coming back may begin to be a serious
  73. load on the sender and cause performance to slowly taper off.
  74.  
  75. Users contemplating huge fanouts, say to hundreds of processes, will want
  76. to build some form of tree structure.  Read the posting from 2 weeks ago
  77. about the "O" option to cbcast if you do something like this, with multiple
  78. overlayed groups.
  79.  
  80. We are willing to take on beta users starting in mid January.  
  81.  
  82. Please feel free to comment or flame about this.  I am interested in
  83. feedback and hearing questions.
  84. -- 
  85. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  86. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  87. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  88.