Subject: [SAM] SAM RG next steps

From: "John Buford" <[email-masked]>
Date: Thu, 3 Jan 2008 16:14:29 -0500

Hi Xiaoming,

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.

IDs were written on 1,2, and 3.  They have been presented in several RG
meetings
with some discussion and no objections.  It is not clear how much more
should be
done on 1 and 2 IDs.  I don't know that we should try to push them to
informational
RFCs. Possibly new scenarios from IPTV or P2P video delivery systems could
be
incorporated into them.

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.

As for (3), I plan to update (3) before the next meeting.
The goal of the SAM framework is to permit multiple ALM schemes to co-exist
in the
same multicast overlay for experimentation purposes.  The ALM schemes I
think are
most promising are those which are built on a P2P overlay.  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.

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.

We should first agree on the SAM Framework approach.
Comments, counter proposals, etc. are welcomed.

John

On Jan 3, 2008 3:49 PM, Xiaoming Fu <[email-masked]> wrote:

> Hi John,
>
> Thanks for your quick response.
> John Buford wrote:
> > Xiaoming,
> >
> > Thanks for raising these points.  Please see the separate email on
> > SAM RG 2007 report for a partial answer to the question,
> > where are we now?
>
> Maybe it could have been clearer, if action items were more visible to
> the RG on what we intend to next. Some additional comments to your
> comments.
>
> <deleted>
_______________________________________________
SAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sam

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 3 Jan 2008 23:56:37 +0100

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.

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

  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.

> 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:[email-masked]   :. Germany, mailto:[email-masked]
:. http://home.fhtw-berlin.de/~mw       :. http://www.link-lab.net

---

From: "John Buford" <[email-masked]>
Date: Thu, 3 Jan 2008 18:06:17 -0500

Hi Matthias,
These are interesting points

> ... And a comprehensive problem statement gives a good starting point for

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.

> 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).

> framework maybe borrowed from IGMP/MLD. That could be also an outcome of

I think there is a proposed ALM API in the RG that was discussed at IETF-69.
Is this what you are thinking of?

---

From: "John Buford" <[email-masked]>
Date: Thu, 3 Jan 2008 18:06:17 -0500

Hi Matthias,

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 4 Jan 2008 12:54:05 +0100

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

---

From: "John Buford" <[email-masked]>
Date: Fri, 4 Jan 2008 15:09:53 -0500

Perhaps the SAMTK designers could comment on this discussion?

---

From: Xiaoming Fu <[email-masked]>
Date: Sat, 05 Jan 2008 22:58:23 +0100

> Peer-to-Peer Overlays", 2003)?

Probably general p2p overlay protocol is not directly targeted within 
the RG, but p2p/overlay multicast issues may do. There are some current 
efforts within the P2PSIP WG, not sure what about P2PRG...

> framework maybe borrowed from IGMP/MLD. That could be also an outcome of 

Re: group member management seems a good item to work on, maybe we can 
work out something within the group...
Xiaoming

---

From: Nobuo Kawaguchi <[email-masked]>
Date: Sun, 06 Jan 2008 23:07:58 +0900

Hi John, and all,

I'm one of the SAMTK designer. So I should say my opinion.

As I already presented in IETF-69 SAM-RG, SAMTK is 
just a middleware(or toolkit) to ease a development of 
applications and multi-point protocols.
This means that, by using SAMTK, application developers can 
easily develop a multi-point comm app without considering
multi-point protocols. Also protocol researchers can 
utilize real applications just developing a protocol plug-in
for SAMTK.

We also provide a group management API in SAMTK.
We already implement a Web based centralized group management. 
But API does not limit the implementation.
(We also planning to implement a P2P/DHT based group management.)
 
As you already mentioned, API in SAMTK could be more general.
However, we do not know what kind of communication pattern 
will be suitable for multi-point group communication and 
group management.
This means, definition of "common" API is not easy.
So we start from a implementation. 
By using SAMTK as a reference, we can discuss its pros and cons.
We do not hesitate to change the API of SAMTK as a result of
discussions in SAM-RG.

SAMTK is now in beta phase. We are currently preparing English
documents. So please wait a bit.

yours, 

Nobuo Kawaguchi
Graduate School of Engineering, Nagoya Univ., Japan.
[email-masked]

John Buford Wrotes,
> ------------------------------------------------------------------------
>