[SAM] SAM Overlay Protocol

[Matthias Waehlisch]

Hi John,

On Thu, 1 May 2008, John Buford wrote:
>
> > > Isn't "overlay group address" somewhat circular?
> > >
> >  why? There is an underlay and overlay group address. And there are 
> > overlay PeerIds ... Overlay address seems to me a bit unspecified in 
> > the context of multicast.
> 
> Well, because we would be defining Group ID as a group address. "overlay 
> address" is any value in the address space of the overlay.
> 
  ok, I understand. Thus, "A Group-ID is information that uniquely 
identifies a group within a given overlay."

> > > Could you explain in more detail the problem with the current text?  
> > > Are you saying there are instances where the groupId isn't the root 
> > > of the tree?
> > >
> >  Yes, one example for this is CAN multicast. The group address in CAN 
> > is used to address the bootstrap peer. Based on this, the mini CAN 
> > will be constructed. However, data distribution is based on flooding 
> > the mini CAN. As far as I understand: Each member of the mini CAN may 
> > be inherently a source.
> >
> >  Another approach is the bidirectional shared distribution tree, which 
> > we sketched in Chicago 
> > http://www.ietf.org/proceedings/07jul/slides/SAMRG-3.pdf (for the 
> > paper cf. http://www.realmv6.org/bib/ws-buode-07.html) and elaborate 
> > at the moment.
> 
> I was trying to avoid rendezvous schemes where a rendezvous server 
> manages the tree, since I don't think it scales.  That is why I focused 
> on the group address being the root address of the tree.
> 
> We could say that GroupId represents the address in the overlay to which 
> join messages are propagated.  This includes models where the GroupID is 
> the root of the tree, or is a bootstrap or rendezvous point.
> 
  Yes, but one has to adjust all messages, like leave, heartbeat ... 
correspondingly. Maybe one should add a terminology section, which 
explains general terms.

> In reviewing the slides on the shared distribution tree, I guess you are 
> refering to the IMG ids.  I don't see that these are equivalent to 
> GroupIds since a given tree could have multiple IMG ids, one for each 
> network domain it has receivers/senders on. If I understand the slides 
> correctly.
> 
  The IMG ids represent the address of the IMG within the overlay 
(Peer-ID). You are right, these ids don't correspond to group-IDs. The 
group-ID is used to establish states in the underlying overlay multicast 
routing protocol.

> Also are you thinking about making your scheme overlay agnostic?
> 
  Yes, the IMG function is independent of the underlying ALM routing 
protocol.

> Do you have any other suggestions for changes to this document?
> 

  * Should we really predefine, that the inter-region connection is 
implemented by AMT? As far as I understand the draft, it provides a common 
set of messages to establish the overlay distribution on the one hand and 
to incorporate native multicast regions on the other hand. Maybe we can 
say, that AMT is one (mandatory?) option.

  * I'm a bit confused about the sentence in the abstract: "We use AMT 
[...] to connect peers in ALM [...] regions with peers in native multicast 
regions."

  The term "peer" implies that the system participates in the overlay and 
provides routing services. Thus, a peer is connected with the overlay. Or 
do you mean a native multicast client equipped with a JoinViaAMTGateway 
function?

  * In general, it would be helpful to sketch the scenario: Does the SAM 
overlay protocol connect (overlay) peers with native multicast clients 
which are not aware of the overlay?


Thanks
  matthias

-- 
Matthias Waehlisch
:. HAW Hamburg, Dept. Informatik       :. link-lab
:. Berliner Tor 7, 20099 Hamburg       :. Hoenower Str. 35, 10318 Berlin
:. Germany, mailto:waehlisch at ieee.org  :. Germany, mailto:mw at link-lab.net
:. http://home.fhtw-berlin.de/~mw      :. http://www.link-lab.net
:.
:. FU Berlin, Inst. Informatik, Berlin, Germany http://www.mi.fu-berlin.de