[SAM] SAM RG next steps

[Matthias Waehlisch]

Hi John,

On Thu, 3 Jan 2008, John Buford wrote:

> > [...]
> > > In addition, in the P2P-SIP WG there is a proposal for a universal 
> > > P2P overlay protocol. (universal in that it is meant to support the 
> > > operations needed by several multi-hop structured overlays).
> > >
> > > So, the direction I have in mind for the SAM Framework involves: 
> > > extended AMT gateways, ALM on P2P overlay, use of a universal P2P 
> > > overlay protocol.  Then, any researcher could plug their own ALM 
> > > algorithm into this and select their own P2P overlay algorithm as 
> > > well. Meanwhile, the AMT integration means that native multicast and 
> > > ALM can co-exist.
> > >
> >  What does a universal P2P overlay protocol mean in detail? Is it 
> > similar to the common API by Dabek et al. ("Towards a Common API for 
> > Structured Peer-to-Peer Overlays", 2003)?
> 
> I recall the Dabek et al. model is mainly on the DHT level. The protocol 
> also needs to cover overlay maintenance. It starts from the observation 
> that many structured overlays have to send the same types of messages 
> between peers, such as GET, PUT, JOIN, LEAVE, ROUTING-TABLE UPDATE, 
> PROBE, etc.  But the details vary from overlay to overlay.  So the 
> protocol covers the common message types with basic fields plus 
> extension mechanisms.
> 
  there is a detailed description for the KBR (key based routing) layer 
and some very rough ideas for multicast (CAST).

  The problem of the Dabek et al. model from my point of view is that it 
intermingles semantic definitions with algorithmic logic. The CAST 
abstraction for example provides standard group membership methods (join, 
leave, ...) on the one hand and tree maintenace description similar to 
SCRIBE on the other hand.

> >  Btw: It makes sense to have an interface definition between ALM 
> > 'stack' and application. But this should be a part of a common group 
> > membership framework maybe borrowed from IGMP/MLD. That could be also 
> > an outcome of SAM RG.
> 
> 
> I think there is a proposed ALM API in the RG that was discussed at 
> IETF-69. Is this what you are thinking of?
> 
  Do you mean the SAMTK? Hm, I think partly, because SAMTK is an 
implementation as far as I understand. It can be seen as a standard stack, 
however, it would be fine to have a document as a general ALM group 
membership guidance. This includes definition of group management methods 
(as done in SAMTK), a general packet format, etc. ... The SAMTK 
definitions for example differ from the interfaces in the Dabek et al. 
model. If we are looking on implementations in different ALM simulators we 
will also find discrepancies, although some of them rely on the Dabek et 
al. model.

  Another point is the question of broadcast as a special case of 
multicast. How should we define it: Should the application developer join 
a special multicast group - but which one? Or should we define a separate 
broadcast socket/interface?

  All of these could be addressed in a common group membership description 
for ALM. I feel a bit uncomfortable with too many approaches being around 
on this basic topic.

Cheers
  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