Subject: [tsvwg] Draft IETF message to disclose Transactional Multicast within Clusters

From: Caitlin Bestler <[email-masked]>
Date: Tue, 26 Aug 2014 09:03:46 -0700

Nexenta has been developing a multicast based transport/storage protocol for Object
Clusters at Nexenta. This applies multicast datagrams to creation and replication of
Objects such as those supported by the Amazon S3 protocol. Creating replicas of  object
payload on multiple servers is an inherent part of any storage cluster, which makes
multicast addressing very inviting.  There are issues of congestion control and
reliability to settle, which we were able to do.

However, we found that the existing protocols for controlling multicast group membership
(IGMP and MLD) are not suitable for our storage application. We doubt  this is unique to
our application. It should apply to many clusters that have a need to distribute
transactional messages to dynamically selected subsets of a group within a cluster to
multiple known recipients. HPC clusters using MPI are also potential users of transactional
multicasting. Multicast repication over a VLAN for the internal communications of a pNFS
cluster is another potential application. This is just one example of synchronizing cluster
data where the synchronization does not replicate all of the shared data with the entire
cluster. But these are merely initial hunches, the purpose of this email is to determine exactly
how common the need for “transactional multicast” is, and possibly to incorporate the needs
of other clusters, before submitting a draft.

To be clear, this is a submission to the IETF process proposing enhanced methods for
controlling multicast group membership. This and later posts may make reference to
specific applications, including the Nexenta Replicast protocol for multicast replication
in our Cloud Copy-on-Write (CCOW) Object Cluster. Such examples are merely for
illustrative purposes. Any IETF standardization of the Replicast storage protocols would
be done via the Storm or NFS groups, and would require adoption of a definition of Object
Storage as a service before defining a specific protocol for providing Object Storage
services.

What will be proposing is focused on the management of multicast groups, specifically two
additional methods for setting the membership of a multicast group which can radically
reduce the latency in setting up a group within a known cluster.

The potential for such dramatic savings is that transactional messaging within a cluster
is a radically different use-case from traditional multicast.
This covers a variety of factors:
* How is the group Selected?
* What are the endpoints that receive the messages?
* What is the duration of the group?
* Who are the potential members of the group?
* How much latency does the application tolerate?

Question 1: How is the Group Selected?

In IGMP/MLD the membership of a multicast group is controlled by the listeners joining and
leaving the group. The sender does not control or even know the recipients. This matches
the multicast streaming use-case very well. However it does not match a cluster that needs
to distribute a transactional message to a subset of a known cluster.

The target group is also assumed to be stable for a long sequence of packets, such as
streaming a video. The targeted applications direct transactions to a subset of a stable group.

One example of the need to distribute a transactional message to a subset of a known
cluster is replication within an object cluster. A set of targets has been selected
through an higher layer protocol. IGMP-style setup here adds excessive latency to the
process. The targets must be informed of their selection, they must execute IGMP joins and
confirm their joining to the source before the multicast delivery can begin. Only
replication of large storage assets can tolerate this setup penalty.

A distributed computation may similarly have data that is relevant to a specific set of
recipients within the cluster. Having to replicate the transfer over multiple unicast
connections is undesirable, as is having to incur the latency of IGMP setup.

Two solutions will be proposed where a sender can form or select a multicast group to
match a set of targets, without requiring any extra interaction with THOSE targets as long
as the targets are already members of a pre-existing multicast group. Allowing a sender to
multicast to *any* set of IP addresses would clearly be unacceptable for both security and
network administration reasons.

Question 2: What are the endpoints that receive the messages?

For the specific storage protocol we were working on the desired endpoints are virtual
drives, not IP endpoints. A given storage server can determine which of its virtual drives
is being addressed solely from the destination multicast IP address.

One of the questions for the mailing list is whether this is unique to this storage
protocol, or whether the ability to identify a multicast group as a set of higher layer
objects is generally desirable.

Question 3: What is the duration of the group?

IGMP/MLD is designed primarily for the multicast streaming use-case. A group has an
indefinite lifespan, and members come and go at any time during this lifespan, which might
be measured in minutes, hours or days.

Transactional multicasting seeks to identify a multicast group for the duration of sending
a set of multicast datagrams related to a specific transaction. Recipients either receive
the entire set of datagrams or they do not. Multicast streaming typically is transmitting
error tolerant content, such as MPEG encoded material. Transaction multicasting will
typically transmit data with some form of validating signature that allows each recipient
to confirm full reception of the transaction.

This obviously needs to be combined with applicable congestion control strategies being
deployed by the upper layer protocols. The Nexenta Replicast protocol only does bulk
transfers against reserved bandwidth, but there are probably as many solutions for this
problem as there are applications. Replicast relies upon IEEE I802.1 Datacenter Bridging
(DCB) protocols such as Priority Flow Control and Congestion Notification to provide 
no-drop service. The DCB protocols deal with the fine timing of congestion avoidance,
but require higher layer transport or application protocols to keep the sustained
traffic rates below the sustained capacity. Creating explicit reservations for bulk
transfers is the main method for accomplishing this.

The important distinction between Replicast and conventional multicast applications is
that there is no need to dynamically adjust multicast forwarding tables during the
lifespan of a transaction, while IGMP and MLD are designed to allow the addition and
deletion of members while a multicast group is in use. This distinction is not   unique to
Nexenta's Replicast storage application. Transactional replication is a common
element in cluster protocol design.

The limited duration of a transactional multicast group implies that there is no need for
the multicast forwarding element to rebuild its forwarding tables after it restarts. Any
transaction in progress will have failed, and been retried by the higher-layer protocol.
Merely limiting the rate at which it fails and restarts is all that is required of each
forwarding element.

Another implication is that there is no need for the forwarding elements to rebuild the
membership list of a transactional multicast group after the forwarding element has been
reset. The transactions using the forwarding element will all fail, and be retried by a
higher layer transport or application protocol. Assuming that forwarding elements do not
reset multiple times a minute this will have very limited impact on overall application
throughput.

The duration of a transaction is application specific, but inherently limited. A failed
transaction will be retried at the application layer, so obviously it has a duration 
measured in seconds at the longest.

Question 4: Who are the members of the group?

IGMP/MLD is designed to allow any number of recipients to join or leave a group at will.

Transactional multicast requires that the group be identified as a small subset of a
pre-existing multicast group.

Building forwarding rules that are a subset of forwarding rules for an existing multicast
group can done substantially faster than creating forwarding rules  to arbitrary and
potentially previously unknown destinations.

Question 5: How much latency does the application tolerate?

While no application likes latency, multicast streaming is very tolerant of setup latency.
If the end application is viewing or listening to media, how many msecs are required to
subscribe to the group will not have a measurable impact to the end user.

For transactions in a cluster, however, every msec is delaying forward progress. The time
it takes to do an IGMP join would be a significant addition to the latency of storing an
object in an object cluster using SSD or other fast storage technology.

Proposed Method 1:

Set the multicast forwarding rules for pre-existing multicast forwarding address X to be
the subset of the forwarding rules for existing group Y required to reach a specified
member list.

This is done by communicating the same instruction (above) to each multicast forwarding
network element.  This can be done by unicast addressing with each of them, or by 
multicasting the instructions.

Each multicast forwarder will set its multicast forwarding port set to be the union of the
unicast forwarding it has for the listed members, but result must be a subset of the
forwarding ports for the parent group.

For example, consider an instruction is to create a transaction multicast group I which is
a subset of multicast group J to reach addresses A,B and C.

Addresses A and B are attached to multicast forwarder X, while C is attached to multicast
forwarder Y.

On forwarder X the forwarding rule for new group I contains:
	The forwarding port for A.
	The forwarding port for B.
	The forwarding port to forwarder Y (a hub link). This eventually leads to C.

While on forwarder Y the forwarding rule for the new group I will contain:
	The forwarding port for forwarder X (a hub link). This eventually leads to A and B.
	The forwarding port for C.

Many ethernet switches already support command line and/or SNMP methods of setting these
multicast forwarding rules, but it is challenging for an application to reliably apply the
same changes using multiple vendor specific methods. Having a standardized method of
pushing the membership of a multicast group from the sender would be desirable.

Proposed Method 2:

There is a large group of pre-configured multicast groups which are an enumeration of the
possible subsets of a master group. This will be a specific subset, such as all
combinations of 3 members for multicast group X. These groups are enumerated and assuaged
successive multicast addresses within a block.

The sender first obtains exclusive permission to utilize a portion of the reception
capacity of each desire target, and then selects the multicast address that will reach
that group.

In a straightforward enumeration of 3 members out of a group of 20, there are 20*19*18/3*2
or 1040 possible groups. Typically the higher layer protocol will have negotiated the
right to send the transaction with the member prior to selecting the multicast group. In
making the final selection, the actual multicast group is
selected and some offered targets are declined.

Those 1040 possible groups can be enumerated in order (starting with M1, M2 and M3 and
ending with M18, M19 and M20) and assigned multicast addresses from N to N+1039.

When the transaction requires reaching M4, M5 and M19, you simply select that group.
Because exclusive rights to use multicasting to M4, M5 and M19 have already been obtained
through the higher layer protocol the group [M4,M5,M19] is already exclusively claimed.

These 1040 groups may be set up through any of the following means:
* Traditional IGMP/MLD joining/leaving.
* Setting static forwarding rules using SNMP MIBs and/or switch-specific command line
 interfaces. Note that the wide-spread existence of command line interfaces to custom
 set multicast forwarding rules is an indicator that there are existing applications
 that find the exising IGMP/MLD protocols to be inadequate to fulfill their needs.
* Method 1 as described previously.

Security Considerations

The methods described here enable no sender to multicast messages to any destination
that was not already addressable by it. Therefore no new security vulnerabilities
are enabled by these techniques.

Summary

The proposal provides for two new methods to manage multicast group membership,
Thee are simple techniques, but provide  a cohesive cluster-wide approach to providing
transactional multicasting. These techniques are better suited for transactional multicasting
that the existing methods, IGMP and MLD, which are oriented to the streaming use-cases.

Caitlin Bestler
[email-masked]
[email-masked]

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 28 Aug 2014 10:02:26 -0700

On Aug 26, 2014, at 8:43 PM, Dave Taht <[email-masked]> wrote:

> This made my head hurt. Got code?

This is a very distributed algorithm. Actual code would be very dependent on implementation specifics
at each of the execution locations.

But to break this down, there are four relevant locations in this protocol:

1) The sender
2) The data plane forwarder of multicast frames/packets in the switch/mrouter.
3)The software which updates the control data that the data plane forwarder uses.
    This may be a processor that is part of the switch/mrouter. Concieably this could be
    built “in-line” in the forwarding chip, but that is not required and is probably not desirable.
   The amount of logic that can be considered trivial grows every year, so I don’t want to state
   that it would *never* be done in-line, but I wouldn’t want to buy such a switch anytime soon.
4) The receiver.

Something that I neglected to highlight in the first message is that 2) is unchanged from
existing switches/mrouters. This was a major constraint on the design, but it can be so
obvious when your working on it that you can forget to state it.

The detailed logic example for Method 1 provide in the original post applies to 3) the forwarder-associated
editing of the data used by the data plane to control multicast forwarding.

>>        The forwarding port for C.

This assumes the common data plane forwarding model:
* VLAN ID + multicast address indexes to a set of ports. The frame is forwarded on all of those ports except the port the frame arrived upon.

So the forwarding port set to reach [A,B,C] is the union of the  port sets for [A],[B] and [C].

This is done when the dynamic transactional multicast group is set, not on a per frame/packet basis.

For method 1 the sender and the receivers have agreed to transmit a transaction on transaction multicast group X, and that the membership
of the transactional group will be [A,B,C]. Rather than having A,B and C use IGMP/MLD to *join* the group, the sender uses method 1 to
*push* the membership of the group to the relevant switches/mrouters.

Method 2 has the same two layer approach. The setup command is just more ambitious.
It is creating a large set of transactional multicast groups to cover every legitimate set of targets
within an existing multicast group.  For example, all combinations of 3 members of a 10 member
reference group.

One implementation would be as follows:

	t_group = base_t_group
	do
		set forwarding rule for t_group to union of forwarding ports for t_group’s members
		t_group = t_group + 1
	while permuting membership yields a new combination

With method 2 the sender uses the master group (referred to as the “Negotiating Group” in Nexenta’s Replicast protocol) to announce which
of the pre-existing transactional_groups will be used to complete a given transaction. That transctional group is now associated with the
transaction because each of the receivers has already granted some form of exclusive right to multicast to it for a specific overlapping 
duration. This may be exclusive to the port/VLAN, or could conceivably be for a more specific scope. This is dependent on the higher
layer protocol that is using these new methods for creating transactional multicast groups.

---

From: Dave Taht <[email-masked]>
Date: Thu, 28 Aug 2014 11:06:59 -0700

> at each of the execution locations.

Point being it's easier to grok with an example in front of me.
Running code and rough consensus and all that.

The main multicast transfer protocol I work with is uftp, which relies
on IGMP also, does not require any changes at the switch level (relies
on an application level proxy to forward across domains, which, could,
indeed, run on a switch), and uses tcp-friendly techniques to do its
job.

(see: http://uftp-multicast.sourceforge.net/ for details of the app,
protocol, and methods)

How does the intent and practice differ for your protocol vs uftp?

-- 
Dave Täht

http://www.bufferbloat.net

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 28 Aug 2014 11:19:39 -0700

> How does the intent and practice differ for your protocol vs uftp?

The key difference is that transactional multicasting is aimed at performing multiple high bandwidth transfers within a single cluster concurrently.

Within the scope of the cluster the application protocol can be much more aggressive at running the transfers at near wire speed by relying
on the combination of a reservation and 802.1 DCB protocols such as PFC, ETS and CN.

With slower long-haul file transfers (“over the web” versus “inside a cluster”) the overhead of IGMP/MLD group creation is tolerable.
UFTP *could* use the techniques described here, if the scope was doing transfers within a pre-existing group. Support for long-haul
multicast is very thin outside of data centers, however, so I doubt this would make sense for most UFTP users.

The example cited of doing replication within a pNFS cluster is closer to the Replicast object cluster that led to our developing transactional
multicasting. Like uftp, you are transferring to a set of known members that are selected by the sender, and the selection is from within a
known set of destinations.

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 Aug 2014 14:24:55 -0400

Caitlin,

The interest is appreciated, but this message itself is long enough that it
also would benefit from being written up and submitted as an Internet Draft,
among other things because multicast work and interest in multicast extends
well beyond the tsvwg WG and the transport area.

Thanks,
--David (tsvwg WG co-chair)

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> Sent: Tuesday, August 26, 2014 12:04 PM
> To: [email-masked]
> Subject: [tsvwg] Draft IETF message to disclose Transactional Multicast within
> Clusters
> 
> how common the need for "transactional multicast" is, and possibly to incorporate the needs

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 Aug 2014 19:45:38 +0100

Carsten,

Thanks for this long and content-rich email.

I think I understand why you brought this to TSV, but it seems to me that a lot
of the discussion is about the appropriateness of MLD and IGMP.

The expertise for that stuff is in the PIM WG and a little in the INT Area.

I wonder whether you would like to try to kindle discussion there as well.

Thanks,
Adrian

> Sent: 26 August 2014 17:04
> To: [email-masked]
> Nexenta has been developing a multicast based transport/storage protocol for
> Object  Clusters at Nexenta.

[snip]

---

From: [email-masked]
Date: Thu, 28 Aug 2014 19:56:24 +0100

I'm not sure you express the problem in a way I understand as an IP
multicast person - see some comments in-line, but I stopped half-way
through because I think this isn't the right place to unpack this.

I  think actually a lot of this is a topic related to MBONED/PIM WG - the
task of controlling L2 membership lies somewhere between these groups. 
However, if your proposal is more linked to direct communication with
switches, perhaps you should first compare this with GMRP, etc.

A short draft would certainly help a lot to clarify the issues and help
people discuss. I'd be happy to review a draft, or help find other
contacts in the IETF who can help (if that is useful).

Gorry
tsvwg co-chair

>> In IGMP/MLD the membership of a multicast group is controlled by the
>> listeners
>> joining and
>> leaving the group. The sender does not control or even know the
>> recipients.
>> This matches
>> The target group is also assumed to be stable for a long sequence of
>> packets,
>> such as
>> streaming a video. The targeted applications direct transactions to a
>> subset
>> of a stable group.
>>
Not necessarily, multicast is used in other ways as well. Sometimes apps
join to groups and the server occasionally sends to a specific group to
target a specific subset of hosts that it knows is listening.

>> One example of the need to distribute a transactional message to a
>> subset of a
>> known
>> cluster is replication within an object cluster. A set of targets has
>> been
>> selected
>> through an higher layer protocol. IGMP-style setup here adds excessive
>> latency
>> to the
>> process.
>>
I didn't get the problem, why does an IGMP join cause delay? - My mental
model would have thought the clients had already joined to the group when
they started running the service, and simply "waited" for something to
arrive.

>> The targets must be informed of their selection, they must
>> execute
>> IGMP joins and
>> confirm their joining to the source before the multicast delivery can
>> begin.
>>
That sounds rather odd - multicast apps that I know are not built this
way. The starting of the client, generally registers to a set of groups.
The server doesn't wait for clients to join - if you want to synchronise
then that's a transport issue, not a L2 membership one.

>> Only
>> recipients within the cluster. Having to replicate the transfer over
>> multiple
>> unicast
>> Two solutions will be proposed where a sender can form or select a
>> multicast
>> group to
>> match a set of targets, without requiring any extra interaction with
>> THOSE
>> targets as long
>> as the targets are already members of a pre-existing multicast group.
>> Allowing
>> a sender to
>> multicast to *any* set of IP addresses would clearly be unacceptable for
>> both
>> security and
Ah you mean you would like to do L2 security, that's a complicated thing
in multicast - there are proposals in the mboned WG, but this isn't part
of the classic multicast service model.

>> For the specific storage protocol we were working on the desired
>> endpoints are
>> virtual
>> drives, not IP endpoints. A given storage server can determine which of
>> its
>> virtual drives

I think you need to write-up the problem.

>> IGMP/MLD is designed primarily for the multicast streaming use-case.
>>
Not really.

>> A group has an
>> a set of multicast datagrams related to a specific transaction.
>>
You can use the port space and build apps on the network service this
provides which can themselves filter on the data they receive - several
apps do this, and work with existing L2 switches.

>> Recipients
>> either receive
>> the entire set of datagrams or they do not. Multicast streaming
>> typically is
>> transmitting
>> typically transmit data with some form of validating signature that
>> allows
>> each recipient
>> deployed by the upper layer protocols. The Nexenta Replicast protocol
>> only
>> does bulk
>> transfers against reserved bandwidth, but there are probably as many
>> solutions
>> for this
>> (DCB) protocols such as Priority Flow Control and Congestion
>> Notification to
>> provide
>> no-drop service. The DCB protocols deal with the fine timing of
>> congestion
>> avoidance,
>> traffic rates below the sustained capacity. Creating explicit
>> reservations for
>> bulk
>> that there is no need to dynamically adjust multicast forwarding tables
>> during
>> the
>> deletion of members while a multicast group is in use. This distinction
>> is not
>> unique to
>> The limited duration of a transactional multicast group implies that
>> there is
>> no need for
>> the multicast forwarding element to rebuild its forwarding tables after
>> it
>> restarts. Any
>> transaction in progress will have failed, and been retried by the
>> higher-layer
>> protocol.
>> Another implication is that there is no need for the forwarding elements
>> to
>> rebuild the
>> reset. The transactions using the forwarding element will all fail, and
>> be
>> retried by a
>> reset multiple times a minute this will have very limited impact on
>> overall
>> application
>> throughput.
>>
>> The duration of a transaction is application specific, but inherently
>> limited.
>> A failed
>> transaction will be retried at the application layer, so obviously it
>> has a
>> duration
>> IGMP/MLD is designed to allow any number of recipients to join or leave
>> a
>> group at will.
>>
>> While no application likes latency, multicast streaming is very tolerant
>> of
>> setup latency.
>> If the end application is viewing or listening to media, how many msecs
>> are
>> required to
>> it takes to do an IGMP join would be a significant addition to the
>> latency of
>> storing an
>> the subset of the forwarding rules for existing group Y required to
>> reach a
>> specified
>> member list.
>>
>> This is done by communicating the same instruction (above) to each
>> multicast
>> forwarding
>> network element.  This can be done by unicast addressing with each of
>> them, or
>> by
>> Each multicast forwarder will set its multicast forwarding port set to
>> be the
>> union of the
>> unicast forwarding it has for the listed members, but result must be a
>> subset
>> of the
>> For example, consider an instruction is to create a transaction
>> multicast
>> group I which is
>> Addresses A and B are attached to multicast forwarder X, while C is
>> attached
>> to multicast
>> forwarder Y.
>>
>> Many ethernet switches already support command line and/or SNMP methods
>> of
>> setting these
>> same changes using multiple vendor specific methods. Having a
>> standardized
>> method of
>> possible subsets of a master group. This will be a specific subset, such
>> as
>> all
>> combinations of 3 members for multicast group X. These groups are
>> enumerated
>> and assuaged
>> The sender first obtains exclusive permission to utilize a portion of
>> the
>> reception
>> capacity of each desire target, and then selects the multicast address
>> that
>> will reach
>> that group.
>>
>> In a straightforward enumeration of 3 members out of a group of 20,
>> there are
>> 20*19*18/3*2
>> right to send the transaction with the member prior to selecting the
>> multicast
>> group. In
>> Those 1040 possible groups can be enumerated in order (starting with M1,
>> M2
>> and M3 and
>> When the transaction requires reaching M4, M5 and M19, you simply select
>> that
>> group.
>> Because exclusive rights to use multicasting to M4, M5 and M19 have
>> already
>> been obtained
>> through the higher layer protocol the group [M4,M5,M19] is already
>> exclusively
>> claimed.
>>
>>  interfaces. Note that the wide-spread existence of command line
>> interfaces to
>> custom
>>  that find the exising IGMP/MLD protocols to be inadequate to fulfill
>> their
>> needs.
>> Thee are simple techniques, but provide  a cohesive cluster-wide
>> approach to
>> providing
>> that the existing methods, IGMP and MLD, which are oriented to the
>> streaming
>> use-cases.
>>
>>
>>
>>
>>
>> Caitlin Bestler

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 28 Aug 2014 13:22:23 -0700

> contacts in the IETF who can help (if that is useful).

Actually the group that has the most relevant expertise is probably TRILL,
but this is a complete non-fit with the TRILL charter.

But I’ll repackage the proposal and submit to the other groups suggested
within the next day or so.

> target a specific subset of hosts that it knows is listening.

The IGMP/MLD protocols have features to maintain forwarding of packets
to the group members even in the event of network re-configuration.

That is a valuable feature, for target groups that have an indefinite life span.
It is worthless overhead for transactions measured in seconds or msecs.

> they started running the service, and simply "waited" for something to

The IGMP join can take longer than the actual transfer.

The receiving members have joined the reference or master group already,
but we want to deliver to a subset of that group. Specifcially so that we can
have two disjoint subsets delivering concurrently. This implies that the 
selection of members for the subset groups is some form of load balancing.
For storage this could be latency and/or capacity balancing. But dispatching
work within a cluster would also want to assign members to different subset
groups on a transactional basis.

The first draft of our Repicast storage protocol had the receivers join the
transactional group. What we found is that the latency of the joins made
the overall transaction take way too long except when the chunks to be
transferred were quite large.

We are currently using what was described in proposal 2, because it the
transactional groups can still be formed using IGMP/MLD. We are planning
on adding option 1 for specific switch models in a later release.

The point is that IGMP takes *far* too long for transactional purposes
within a cluster. I believe this is inherently related to requirements that
traditional multicast groups have legitimate needs for. That’s why I don’t
think of this as “challenging” IGMP/MLD, it is mmerely identifying a different
use-case for multicast communications. IGMP/MLD works well of what they
were designed for, but not transactions within a cluster.

> then that's a transport issue, not a L2 membership one.

Chicken and egg problem. Multicast apps do not do this because 
the multicast tools do not support them. The fact that I was familiar
with how switches actually forward frames (for both unicast and
multicast) might have been why the overall solution occurred to me.
If my thinking had been guided by IGMP/MLD I would have rejected
using multicast for bulk transfers.

The upper layer logic required here is doing no-drop bulk transfers.
The recent DCB extensions to Ethernet make a multicast congestion
protocol feasible. Any attempts to do this pre-DCB would have been
futile because the L4 transport protocol would never get the precise
timing right. The fudge factors required would have wasted more 
bandwidth than TCP does.

> of the classic multicast service model.

Im relying on existing controls of the reference multicast groups, both
standards based and existing techniques used by intrusion detection systems
and firewalls.

The point is that the subset rule prevents the introduction of any new
attack vectors. You cannot use these new methods of forming multicast
groups to reach any unwilling targets that you could not have reached
already.

Without such a feature the ability of a *sender* to add a target to a multicast
group could be used for a Denial of Service attack.

> apps do this, and work with existing L2 switches.

Receiver filtering does not work if you want to enable concurrent transfers
to disjoint subsets of an existing multicast group.

The goal is to support a cluster distributing bulk data to be processed and/or
stored by dynamical selected subsets of the entire group. Dropping irrelevant
data in the destination stack does not help if the links going to the destination
become overloaded.

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Aug 2014 14:07:43 -0700

On 8/28/2014 1:22 PM, Caitlin Bestler wrote:
>
> On Aug 28, 2014, at 11:56 AM, [email-masked]
> <mailto:[email-masked]> wrote:
>
>>

I don't see this as having any relationship to TRILL; TRILL is about 
using Internet routing protocols for L2, and is not at all related to 
multicast or application-layer group membership.

Joe