[SAM] SAM RG next steps

[John Buford]

Perhaps the SAMTK designers could comment on this discussion?

On Jan 4, 2008 6:54 AM, Matthias Waehlisch <waehlisch at ieee.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/sam/attachments/20080104/24f00a37/attachment.html