Subject: Comments on zmaap-01.txt

From: Stuart Cheshire <[email-masked]>
Date: Fri, 20 Jul 2001 17:08:37 -0700

General Comment: I fear we have to 'bite the bullet' and face that 
because of the shared nature of multicast addresses, we need an atomic 
"claim and name" operation. That means that claiming and naming have to 
be the same protocol, in the Zeroconf case. The problem is simply this: A 
client says, "Join group FOO. Oh, group FOO doesn't exist. Create group 
FOO." What if two clients do it at the same time? Standard test-and-set 
race condition.

Specific comments on the draft:

Pet Peeve: References are supposed to be an addition to written prose, 
not a substitute for it. References are there so that when an 
inexperienced reader doesn't understand a statement you make, they know 
where to look for more information. References are there so that when an 
*experienced* reader doesn't *agree* with a statement you make, they can 
find upon what prior work you are basing your questionable assertion. You 
should be able to delete the references from a piece of text and have it 
still make sense to an experienced reader. Put another way, the reader 
shouldn't have to keep flipping to the back of the document to understand 
what a sentence is saying. There are several places in the draft that 
fail this test:

>   This document uses the following terms:
>
>   Multicast
>     IP Multicast, as defined in [10] and [11].
>
>   Multicast Address
>     An IP multicast address or group address, as defined in [10]
>     and [3]. An identifier for a group of nodes.
>
>   Multicast Scope
>     A range of multicast addresses configured so that traffic
>     sent to these addresses is limited to some subset of the
>     internetwork. See [6] and [3].

Without the list of references to hand, this makes little sense.

You can fix this two ways:

1. Delete spurious words:

>   This document uses the following terms:
>
>   Multicast
>     IP Multicast [10] [11].
>
>   Multicast Address
>     An IP multicast address or group address [3] [10].
>     An identifier for a group of nodes.
>
>   Multicast Scope
>     A range of multicast addresses configured so that traffic
>     sent to these addresses is limited to some subset of the
>     internetwork [3] [6].

2. Write complete prose:

>   This document uses the following terms:
>
>   Multicast
>     IP Multicast, as defined in "Host Extensions for IP Multicasting"
>     [10] and "Internet Protocol, Version 6 (IPv6) Specification" [11].
>
>   Multicast Address
>     An IP multicast address or group address, as defined in "IP
>     Version 6 Addressing Architecture" [3] and "Host Extensions
>     for IP Multicasting" [10]. An identifier for a group of nodes.
>
>   Multicast Scope
>     A range of multicast addresses configured so that traffic
>     sent to these addresses is limited to some subset of the
>     internetwork. See "IP Version 6 Addressing Architecture" [3]
>     and "Administratively Scoped IP Multicast" [6].

I also prefer to use semidescriptive references instead of numeric 
references so an experienced reader can recogise the reference in 
context, instead of having to flip to the back of the document to find 
out what "[10]" means:

>   This document uses the following terms:
>
>   Multicast
>     IP Multicast [RFC 1112] [RFC 2460].
>
>   Multicast Address
>     An IP multicast address or group address [RFC 1112] [RFC 2373].
>     An identifier for a group of nodes.
>
>   Multicast Scope
>     A range of multicast addresses configured so that traffic
>     sent to these addresses is limited to some subset of the
>     internetwork [RFC 2365] [RFC 2373].

To give credit where it is due, the draft does also contain some examples 
of proper use of references:

>   Servers and network administration staff are not available in all
>   environments. Home networks and ad-hoc networks, for example, need to
>   rely entirely on zero-configuration protocols [14].

>   Hosts may also use MADCAP [2] for these features.

---

More comments:

>   Home networks and ad-hoc networks, for example, need to
>   rely entirely on zero-configuration protocols [14].

Hard to defend this statement as written. How about:

"Many networks without administrative support need to rely..."

>   As described in [5], a host provides two main services to its
>   multicast applications through some API. First, it must allow
>   applications to enumerate the set of available multicast scopes.

This draft talks in several places about "enumerating the set of 
available multicast scopes", but doesn't begin to discuss how this should 
be done on a zeroconf network with no servers. I think that needs to be 
explained.

>   A mini-MAAS send AIU messages for the addresses that it currently has
>   allocated, before their allocation lifetime expires.

This sounds like periodic messages to me. Not good. I know you want to 
detect conflicts, but what is a multicast conflict? A multicast conflict 
is an application getting packets it doesn't want. If no application is 
getting packets it doesn't want, is there really a conflict? If an 
application is getting packets it doesn't want, perhaps it should call 
some routine like "ZMAAP_Resolve_Conflict()" to tell ZMAAP there's a 
problem.

>   The mini-MAAS issues this message repeatedly.

How many times? What interval? If details are going to be given later, 
the draft should say so.

>   To obtain a multicast address allocation, an application requests a
>   range of addresses

>   The ZMAAP messages have the following common format:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    Version    | Message Type  |         Address Family        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                    Lease descriptor 1 (variable)              /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                      . . .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                    Lease descriptor N (variable)              /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>   The lease descriptor for IPv4 addresses has the following format:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                  Initial address in the range                 |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                   Final address in the range                  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                         Lease Identifier                      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        Lease Lifetime         |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The draft contains no evidence to support the notion that allocating more 
than one address at a time is worth the extra protocol complexity. I know 
that people often talk about things like layered codecs, but in practice, 
how often are they really used? What is the requirement that layered 
codecs have multicast addresses that are numerically consecutive?

What is the mean number of multicast addresses allocated by today's 
multicast applications? I expect the mean is somewhere between 1 and 2. I 
generally favour the simplest possible solution to any problem. To 
convince me otherwise, you would have to show that the overall cost of 
the more complicated solution is less than the cost of *not* doing the 
more complicated solution.

By allocating numerically consecutive chunks of multicast address space 
you get fragmentation (just like a memory heap). You might end up in the 
situation where there are enough addresses available overall for your 
application in the ZMAAP address range, just not enough in any one 
consecutive block. Is that a failure?

>      Value     Address Family
>      -----     --------------
>        1       IPv4
>        2       IPv6

I think you should reference the namespace you're using here (you're not 
inventing a new namespace).

>   The Lease Identifier is used to distinguish allocations of the same
>   address range made by different mini-MAASs. It is assigned by the
>   allocator mini-MAAS, using an implementation dependent method. For
>   example, it can be computed as a hash of the allocator's address and
>   the allocation time (and UDP transmission port in case more than one
>   mini-MAAS resides on the same host).

If Lease Identifiers need to be unique, you should wpecify the algorithm, 
not say "implementation dependent". If the algorithm is 
implementation-dependent, then uniqueness is not assured. (One Mac OS API 
specified that applications provide a unique identifier, e.g. their 
process ID, or their assigned creator code, or the base address of their 
heap in shared memory, etc. Any one of these alone would have worked, 
because each is a unique namespace, but by forcing the developer to 
choose which namespace to use, you get collisions when application A uses 
its heap address and application B uses its assigned creator code, and 
just by chance they happen to be the same binary value.)

Also, "The Lease Identifier is used to distinguish *unrelated* 
allocations of the same address range." If two applications are 
coordinating to share a multicast address, then that's not a conflict, 
and they would use the same Lease Identifier, right, even though two 
different mini-MAASs are involved?

>   If a mini-MAAS receives an ACLM with the same Lease Identifier as an
>   allocation in its allocation record, it MUST respond with an AIU
>   message, immediately.  This AIU message MUST contain the Lease
>   Descriptor present in the allocation record.

Why? If the Lease Identifier is the same, doesn't that indicate a 
non-conflict?

>   Care must be taken to ensure that the range of addresses specified in
>   the AIU does not overlap the range of any other allocation in the
>   allocation record.  If it does, this is an allocation conflict and
>   the mini-MAAS MUST send an AIU containing the Lease Descriptor of the
>   allocation with which the ACLM is in conflict.

A mini-MAASs sends an AIU to advertise the addresses it's using. How can 
one range of addresses it's using be in conflict with another range of 
addresses it's using?

>   If any ranges in the AIU message overlap with recorded allocations
>   but the lease descriptors do not match (different address ranges or
>   lease identifier), then an allocation conflict exists. The mini-MAAS
>   MUST remove the allocation from its allocation record.  The mini-MAAS
>   will inform any local applications registered for the canceled
>   allocation, if it has implemented this functionality (see Appendix
>   A).

Is there no tie-breaker here so that one allocation can remain 
undisturbed?

>6.  Security Considerations
>
>   In the interest of simplicity, this draft does not prescribe a means
>   of securing the multicast auto-configuration mechanism. Thus it is
>   possible that hosts will allocate conflicting multicast addresses for
>   a period of time, or that non-conforming hosts will attempt to deny
>   service to other hosts by allocating the same multicast addresses.

I don't think this will fly. Zeroconf Requirements says, "Zeroconf 
protocols MUST NOT be any less secure than related current IETF-Standard 
protocols." For link-only IPv4-only protocols, this means they *may* be 
no more secure than ARP. Multicast crosses routers, so this special 
dispensation does not apply. Or is ZMAAP *only* for allocating link-local 
multicast addresses?

>Appendix B  Session Management Implications
> [...]
>   An application which receives a session announcement with this
>   attribute may use it to form a Lease Descriptor and request the ZMAAP
>   API to either defend the allocation or for notification if there is
>   an address allocation conflict.  See Appendix B.

Appendix B says, "See Appendix B"?

>   [14]  Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf-
>        reqts-06.txt, November 2000.  Work in progress.

Should be draft-08.

>   [15] Cheshire, S., "Dynamic Configuration of IPv4 link-local
>        addresses", draft-ietf-zeroconf-ipv4-linklocal-01.txt, November
>        2000.  Work in progress.

Should be draft-04.

---

That's it for now.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Erik Guttman <[email-masked]>
Date: Sat, 21 Jul 2001 10:06:49 +0200 (MET DST)

Stuart,

I respond to your substantive points.

> be the same protocol

I suggested the same - basicly carry SDP in ZMAAP.  Dave Thaler emphatically
rejected this:  Keep session discovery and address allocation separate,
he said.  Having never written such software nor deployed it, I defer to him.
Dave?

> be done on a zeroconf network with no servers. I think that needs to be 

This simply means that a zmaap support api has to enumerate the scopes
the underlying implementation can allocate addresses in.

> some routine like "ZMAAP_Resolve_Conflict()" to tell ZMAAP there's a 

The idea is that zeroconf protocols do not require rewrites of 
existing applications. Your suggestion would require rewriting 
multicast applications.  The ZMAAP API could be evoked before a MC
app, even by a separate utility which supplied the allocated address
as initialization parameters.  
 
> How many times? What interval? If details are going to be given later, 

Agreed.
 
> than one address at a time is worth the extra protocol complexity. 

This is the api support required, specified by RFC 2771 and RFC 2908.

> consecutive block. Is that a failure?

Yes, it is a failure, as per RFC 2771.  RFC 2730 and AAP work this way.

> inventing a new namespace).

This is done in the preceding parapraph where we cite [12], which points
to http://www.isi.edu/in-notes/iana/assignments/address-family-numbers

> not say "implementation dependent"

OK.  Could you suggest something?

> different mini-MAASs are involved?

Right.
 
> Why? If the Lease Identifier is the same, doesn't that indicate a 

Yes, this is a non-conflict.  But it is important in some cases to be 
able to verify a lease is supported.  That's what Section 4.4.3 talks about.

> one range of addresses it's using be in conflict with another range of 

Allocation record entries include also cached allocations of other 
mini-MAASs.

> Is there no tie-breaker here so that one allocation can remain 

Not currently.  Got any suggestions?

> dispensation does not apply. Or is ZMAAP *only* for allocating link-local 

You're right.  We already support LL, subnet-local and prefix-based 
MC address allocation.  This needs work.  Any suggestions?

> >   an address allocation conflict.  See Appendix B.

Should say 'see draft-ietf-zeroconf-zmaap-api-00.txt.'

Erik