Subject: Re: [SAM] draft-irtf-sam-hybrid-overlay-framework-02.txt available

From: Eiichi Muramoto <[email-masked]>
Date: Fri, 14 Mar 2008 10:42:42 +0900

John-san

May I ask several questions?

What is the concrete example of the gourpID? 
  - for ASM case
  - for SSM case

Does the framework include the mechanism to prevent the loop?
  - case, 2 separate Native MCast connect with multiple AMT RLYs
  -- ASM case
  -- SSM case

Best Regards,
Eiichi Muramoto

On Wed, 27 Feb 2008 10:18:31 -0500
"John Buford" <[email-masked]> wrote:

> An updated version of the Hybrid Overlay Framework is available.
> 
> draft-irtf-sam-hybrid-overlay-framework-02.txt
> 
> John
> _______________________________________________
> SAM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sam

-- 
Eiichi Muramoto <[email-masked]>

_______________________________________________
SAM mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sam

---

From: "John Buford" <[email-masked]>
Date: Thu, 13 Mar 2008 23:33:40 -0400

> What is the concrete example of the gourpID?

Muramoto-san,
groupID is an id recognized in the overlay routing, generated using
the hash algorithm of the overlay.  this is the same algorithm used
to hash object ids for DHT put and get operations.  the overlay does
key-based routing using these ids.  this method has high probability
of producing unique keys.

I don't think ASM or SSM have a group id.  however an ASM session
has a multicast address, and an SSM session has a (S,G) pair
corresponding to source IP address S and SSM destination address G.

So the idea in the framework is to create an association between
the groupID which represents the ALM tree and the multicast address
used in the native layer for the same session.  it is easy to store
the mapping in the DHT for any peer to lookup.

>  - case, 2 separate Native MCast connect with multiple AMT RLYs
there is no loop detection/prevention in the draft currently.
should we add it?

is loop detection algorithm dependent?  The framework is
algorithm agnostic.  if someone adds their algorithm X
to the framework, could the include loop detection for
algorithm X?  or is there a general solution that works
for all tree/mesh formation and data delivery algorithms?
Personally I don't think there is a single general solution,
so it is better to let specific algorithm deal with it.

a loop at the native and/or AMT layer is a different matter.
I haven't thought about it, perhaps others on the list can comment.

Best regards,
John