[SAM] SAM RG next steps

[John Buford]

Hi Matthias,
These are interesting points

On Jan 3, 2008 5:56 PM, Matthias Waehlisch <waehlisch at ieee.org> wrote:

> Hi John,
>
> On Thu, 3 Jan 2008, John Buford wrote:
>
> > I believe the charter stipulates that the RG works on: 1) problem
> > statement, 2) requirements/driving scenarios, 3) framework, 4)
> > evaluation through implementation, analysis or simulation.
>
> [...]
>
> > Question: Should the RG try to push a problem statement / requriements /
> > use cases into an informational RFC? If not, then these documents will
> > probably stay in the expired state.
> >
>  I think yes. It doesn't seem obvious why an Internet Draft should go to
> expire: Is the topic sufficiently discussed or is the draft insufficient
> ... And a comprehensive problem statement gives a good starting point for
> further work.


I agree that auto-expiring IDs in RGs may not be necessary to the
extent that it is in WGs.

The possibility of producing an informational RFC in RGs has only recently
started.  It appears to be some effort to make an ID ready for this stage.


>
>
> [...]
> > 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.

I think an example of this in practice is the OverlayWeaver implementation
which supports a number of different overlay algorithms using a generic
message layer. (OW also follows the Dabek et al. proposal at the DHT API
layer).


>
>
>  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?


>
>
> > That's the general idea.  We could either build this in PlanetLab or
> > devise a simulation environment so that multiple research groups can
> > share it.
> >
>  Or in both - like the approach in OverSim which allows to incorporate
> real-world traffic into the simulator.
>
> 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/20080103/de3c2e74/attachment-0002.html