Subject: zmaap discussion

From: Erik Guttman <[email-masked]>
Date: Mon, 22 Oct 2001 12:52:00 +0200 (MET DST)

Folks,

---

Please note there is an available ZMAAP prototype of 
draft-ietf-zeroconf-zmaap-01.txt specification, under a Sun Public
License:  http://www.neato.org/~femur/iu/jzmaap_01.zip

---

I wrote a new version of ZMAAP with the following agreed upon changes:

 - added a wait to defend timer to prevent defense AIU implosions
 - added a wait to retry allocation timer to prevent thrashing
 - removed text on WEP
 - added a magic number preamble to the ZMAAP header
 - clarified when an allocation conflict occurs (overlapping ranges, 
   same lease id constitutes a conflict)

I submitted this as draft-ietf-zeroconf-zmaap-02.txt, which should
appear shortly.

---

I still have some remaining concerns.

 - The current document still does periodic announcement of allocations
   in order to detect collisions.  AIUs are multicast before the current 
   AIU allocation expires.  This will either be slow (few messages burden
   the network but not very effective at detecting conflicts quickly)
   or fast (would result in many messages being sent for multicast groups
   even if they are not in use)

 - The connection to session discovery is weak.  As specified in ZMAAP,
   SAP is used to passively discover sessions.  This is very slow (repeat 
   rates on the order of 10s of minutes), which is suitable for wide are
   session information distribution but not interactive discovery and
   rendezvous of different applications on one session.

 - Ideally ZMAAP would discover collisions by the basic use of the
   multicast groups in question.  This is how v4 link local address
   autoconf and mDNS discover collisions.  No traffic, no name resolution?
   Then no conflict.  The very act of replying to an ARP or a MDNS request
   allows conflict detection.  

I believe we could add a very simple mechanism to ZMAAP to make it
a session discovery protocol, responding to the issues above.

  1) Instead of using the socket API to send and receive multicast 
     datagrams to groups associated with addresses allocated with
     ZMAAP - applications may use the ZMAAP API send and receive
     wrapper APIs.  The advantage to the application of doing this
     is that the ZMAAP API will take care to inform other mini-MAASs
     that a session is still live.  

     For active sessions - send an unsolicited AIU every n seconds.  

     Advantage - AIU announcements only occur for active sessions.

  2) Replace the Lease ID (4 byte unsigned integer) with a SDP string
     session description.  At the least, this contains a 'session id'
     string.  At the most, a limited amount of additional session 
     description (say up to 256 bytes, so that at least 4 lease 
     descriptors will fit in a single AIU).

     Advantage:  
       - The session id is descriptive enough to allow rendezvous at 
         specific sessions, even vendor predefined sessions.
       - Passively received AIUs will contain session ids:  A mini-
         MAAS will be able to detect that a single session is 
         associated with multiple addresses.  The 'lowest' address
         wins:  the mini-MAAS informs the application of this via
         the API --- OR --- it could maintain the session to address
         binding transparently to the application, if all sends/
         receives go through the ZMAAP API.

     Disadvantages:  
       - SDP session descriptions are big.  
         That's OK, just include fewer lease descriptors per AIU.  
       - SDP session descriptions could contain sensitive info.
         Either just limit the use of SDP to the session id, that is,
         don't include anything which is private data like video titles. 
         Or employ IPsec with predistributed keys as suggested in the
         security considerations of draft-ietf-zeroconf-zmaap-02.txt

  3) Include a new message in ZMAAP 'SDISC' includes only a ZMAAP
     header followed by a SDP string.  This solicits AIU replies
     where the SDP attribute(s) match.  Use the same algorithm to
     reply as for defense (that is, a start a timer and only reply
     if the timer expires before anyone else has replied).  An
     empty string matches all sessions.

     Advantage
       - Allows rapid, interactive discovery of existing sessions
       - Can be used to check if a session exists before creating 
         one.  This presents a race condition, but 1 and 2 above
         would resolve any duplicate session allocations rapidly.

What do you all think?

Erik