Subject: [Spud] multicast spud

From: Caitlin Bestler <[email-masked]>
Date: Mon, 23 Mar 2015 17:26:07 -0700

The requirements section includes multicast in the list, but the details 
need
some more work. For example: "A tube may be closed by either endpoint."

A multicast session does not have a pair of endpoints. it has an 
initiator (or
maybe more) and zero or more receivers.

The opening of a multicast session obviously needs a different procedure 
than
what is used for unicast.

Nexenta's object cluster systems using multicast UDP to replicate 
storage chunks
within a data center. This relies upon a concept of "Transactional 
multicast" that
is described in draft-bestler-transactional-multicast-00.

This approach to multicast addressing is very compatible with SPUD, 
although the
specific project did not need it because multicasting is limited to a 
single subnet.
But SPUD could enable verifying path details for a wider range 
transactional multicast
delivery. Confirming the MTU, for example, would be essential for 
delivering across
middleboxes.

Other comments:

The "CBOR Map" is unclear as described. I presume that this is the 
balance of the
UDP payload that is somehow mutually exclusive from user-content. That 
should
be explicitly stated and probably made clear in the diagram.

There is a rationale that is not explained. If a tube is a specific set 
of datagrams
there is obviously some method of enumerating what is a complete set. 
SPUD is
deliberately limiting its knowledge of this to knowing the first and 
last datagram
because the middleboxes do not need to know how to validate the payload. 
Therefore
while this information is needed, the protocol will not constrain how it 
is encoded.