Open issues
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 is reserved, and a system MUST NOT send a datagram with a destination address of The address range 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?

Copyright (C) 2003, 2004 Steven Hessing