Unresolved issues will be listed here, together with current thinking on how to revolve the issues.

• How will a servent now whether his ISP supports IP multicast?
  • Use multicast beacon
  • Use a logo that ISPs are allowed to use if they are multicast-enabled?
• Does popular SOHO network equipment support IP Multicast and NAT traversal
  • RFC2588: IP Multicast and Firewalls
  • Linksys: supports IGMP (version ?) NAT support?
  • SMC
  • Netgear
  • D-Link
  • Alcatel
  • A servent will send out the wrong Source IP address in the P2P session announcement page if it is behind a NAT/PAT
• What should the TTL of the P2P session announcement message be, this is probably dependent on the P2P network, just as the format of this message
• Is some kind of time synchronisation necessary? How long would a P2P session announcement message take to propagate? P2P network dependent ofcourse
  • No, time synchronisation is not required. Sessions announcements will include the number of seconds before the session will start
• How large should segments be, and related: what should the transmission rate be?
  • For example, a 4 Mbyte segment at 64Kbit/s takes 500 seconds. Sounds reasonable?
• What size MTU should we use for UDP transmission? What is the IP and UDP overhead?
  • IP: 20 bytes, UDP: 8 bytes, PMTP header: 8 bytes, Payload as large as possible, 1400 bytes?
• What amount of packet-loss can we expect and what is the best FEC overhead to be used?
  • Ball-park figure, 10%???
• About the multicast addresses to be used: The SSM destination address 232.0.0.0 is reserved, and a system MUST NOT send a datagram with a destination address of 232.0.0.0. The address range 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA.
• Security: how can this be attacked? Do SSM sessions need special protection? What is people send duplicate P2P session announcement messages but with different session details?