From sam-bounces@ietf.org Thu May 1 13:48:17 2008 Return-Path: X-Original-To: sam-archive@optimus.ietf.org Delivered-To: ietfarch-sam-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EA93A6A32; Thu, 1 May 2008 13:48:17 -0700 (PDT) X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34173A6A32 for ; Thu, 1 May 2008 13:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psiEVfbLHg-9 for ; Thu, 1 May 2008 13:48:15 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by core3.amsl.com (Postfix) with ESMTP id 5F3343A69F0 for ; Thu, 1 May 2008 13:48:15 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 76so845758wra.10 for ; Thu, 01 May 2008 13:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=BpUbX5iPQf7EBbyJwheawyJnOLuX073kPuDJW7Ido+w=; b=B/+4YeRb0O6+JUb6IRVDvN7S1tccC+8Jkvz/VJq4ch2ZJup6XLi/WIsJgkedIQwNbh9GXPfvoT5VA/lsk3qoCmGcWbsrkAaDGg4TrgKbVaqY4AzJsPSdfSj+bBOfBJX9mYGICpMX5s21PsJeA20OiM4TKVm0K3/amGWin3fABR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CApBzque7aV+zI126nDybdiOI8C5bXLlJIrrmsy24HD+l/xNU3NMlmOaPRICC2y06PKx6C90/Jw9MQ7HQ0Mufkau73ECCUypf51Vt5sHhOmQlkX2N2qZY6+uZ6ywduNy/s8o3OLWSxN2TBMPldtl/cY+nImW301p3ofN+gMXM74= Received: by 10.100.58.2 with SMTP id g2mr3680113ana.108.1209674895093; Thu, 01 May 2008 13:48:15 -0700 (PDT) Received: by 10.100.93.9 with HTTP; Thu, 1 May 2008 13:48:15 -0700 (PDT) Message-ID: <4ce32a820805011348s47f4f29fw7d5b44b0eb406dbd@mail.gmail.com> Date: Thu, 1 May 2008 16:48:15 -0400 From: "John Buford" To: "Matthias Waehlisch" In-Reply-To: MIME-Version: 1.0 References: <4ce32a820804291821r62d2aeafk8d3015e3f4077c@mail.gmail.com> X-Google-Sender-Auth: 9a28369b2dedf864 Cc: sam Subject: Re: [SAM] SAM Overlay Protocol X-BeenThere: sam@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: buford@samrg.org List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1188745467==" Sender: sam-bounces@ietf.org Errors-To: sam-bounces@ietf.org --===============1188745467== Content-Type: multipart/alternative; boundary="----=_Part_11547_24593298.1209674895084" ------=_Part_11547_24593298.1209674895084 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Matthias, On Wed, Apr 30, 2008 at 3:48 AM, Matthias Waehlisch wrote: > Hi John, > > On Tue, 29 Apr 2008, John Buford wrote: > > > Isn't "overlay group address" somewhat circular? > > > why? There is an underlay and overlay group address. And there are > overlay PeerIds ... Overlay address seems to me a bit unspecified in the > context of multicast. Well, because we would be defining Group ID as a group address. "overlay address" is any value in the address space of the overlay. > > > > Could you explain in more detail the problem with the current > > text? Are you saying there are instances where the groupId isn't > > the root of the tree? > > > Yes, one example for this is CAN multicast. The group address in CAN is > used to address the bootstrap peer. Based on this, the mini CAN will be > constructed. However, data distribution is based on flooding the mini CAN. > As far as I understand: Each member of the mini CAN may be inherently a > source. > > Another approach is the bidirectional shared distribution tree, which we > sketched in Chicago > http://www.ietf.org/proceedings/07jul/slides/SAMRG-3.pdf (for the paper > cf. http://www.realmv6.org/bib/ws-buode-07.html) and elaborate at the > moment. > I was trying to avoid rendezvous schemes where a rendezvous server manages the tree, since I don't think it scales. That is why I focused on the group address being the root address of the tree. We could say that GroupId represents the address in the overlay to which join messages are propagated. This includes models where the GroupID is the root of the tree, or is a bootstrap or rendezvous point. In reviewing the slides on the shared distribution tree, I guess you are refering to the IMG ids. I don't see that these are equivalent to GroupIds since a given tree could have multiple IMG ids, one for each network domain it has receivers/senders on. If I understand the slides correctly. Also are you thinking about making your scheme overlay agnostic? Do you have any other suggestions for changes to this document? John > > > Thanks > matthias > > -- > Matthias Waehlisch > :. HAW Hamburg, Dept. Informatik :. link-lab > :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 Berlin > :. Germany, mailto:waehlisch@ieee.org :. Germany, mailto:mw@link-lab.net > :. http://home.fhtw-berlin.de/~mw :. http://www.link-lab.net > :. > :. FU Berlin, Inst. Informatik, Berlin, Germany http://www.mi.fu-berlin.de > ------=_Part_11547_24593298.1209674895084 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Matthias,

On Wed, Apr 30, 2008 at 3:48 AM, Matthias Waehlisch <waehlisch@ieee.org> wrote:
Hi John,

On Tue, 29 Apr 2008, John Buford wrote:

> Isn't "overlay group address" somewhat circular?
>
 why? There is an underlay and overlay group address. And there are
overlay PeerIds ... Overlay address seems to me a bit unspecified in the
context of multicast.
 
Well, because we would be defining Group ID as a group address.
 
"overlay address" is any value in the address space of the overlay.
 


> Could you explain in more detail the problem with the current
> text?  Are you saying there are instances where the groupId isn't
> the root of the tree?
>
 Yes, one example for this is CAN multicast. The group address in CAN is
used to address the bootstrap peer. Based on this, the mini CAN will be
constructed. However, data distribution is based on flooding the mini CAN.
As far as I understand: Each member of the mini CAN may be inherently a
source.

 Another approach is the bidirectional shared distribution tree, which we
sketched in Chicago
http://www.ietf.org/proceedings/07jul/slides/SAMRG-3.pdf (for the paper
cf. http://www.realmv6.org/bib/ws-buode-07.html) and elaborate at the
moment.
 
 
I was trying to avoid rendezvous schemes where a rendezvous server manages
the tree, since I don't think it scales.  That is why I focused on
the group address being the root address of the tree. 
 
We could say that GroupId represents the address in the overlay
to which join messages are propagated.  This includes models
where the GroupID is the root of the tree, or is a bootstrap
or rendezvous point. 
 
In reviewing the slides on the shared distribution tree, I guess you
are refering to the IMG ids.  I don't see that these are equivalent
to GroupIds since a given tree could have multiple IMG ids,
one for each network domain it has receivers/senders on.
If I understand the slides correctly.
 
Also are you thinking about making your scheme overlay
agnostic?
 
Do you have any other suggestions for changes to this document?
 
 
John
 


Thanks
 matthias

--
Matthias Waehlisch
:. HAW Hamburg, Dept. Informatik       :. link-lab
:. Berliner Tor 7, 20099 Hamburg       :. Hoenower Str. 35, 10318 Berlin
:. Germany, mailto:waehlisch@ieee.org  :. Germany, mailto:mw@link-lab.net
:. http://home.fhtw-berlin.de/~mw      :. http://www.link-lab.net
:.
:. FU Berlin, Inst. Informatik, Berlin, Germany http://www.mi.fu-berlin.de



------=_Part_11547_24593298.1209674895084-- --===============1188745467== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SAM mailing list SAM@ietf.org https://www.ietf.org/mailman/listinfo/sam --===============1188745467==-- From sam-bounces@ietf.org Sat May 3 04:01:43 2008 Return-Path: X-Original-To: sam-archive@optimus.ietf.org Delivered-To: ietfarch-sam-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB473A6CC4; Sat, 3 May 2008 04:01:43 -0700 (PDT) X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F513A6C85 for ; Sat, 3 May 2008 04:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.784 X-Spam-Level: X-Spam-Status: No, score=-101.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rKxowkwNMaf for ; Sat, 3 May 2008 04:01:41 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D0C473A68A6 for ; Sat, 3 May 2008 04:01:40 -0700 (PDT) Envelope-to: sam@irtf.org Received: from e178135208.adsl.alicedsl.de ([85.178.135.208] helo=mw-thinkpad) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JsFUl-000402-OF; Sat, 03 May 2008 13:01:36 +0200 Date: Sat, 3 May 2008 13:01:19 +0200 From: Matthias Waehlisch To: John Buford In-Reply-To: <4ce32a820805011348s47f4f29fw7d5b44b0eb406dbd@mail.gmail.com> Message-ID: References: <4ce32a820804291821r62d2aeafk8d3015e3f4077c@mail.gmail.com> <4ce32a820805011348s47f4f29fw7d5b44b0eb406dbd@mail.gmail.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Cc: sam Subject: Re: [SAM] SAM Overlay Protocol X-BeenThere: sam@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sam-bounces@ietf.org Errors-To: sam-bounces@ietf.org Hi John, On Thu, 1 May 2008, John Buford wrote: > > > > Isn't "overlay group address" somewhat circular? > > > > > why? There is an underlay and overlay group address. And there are > > overlay PeerIds ... Overlay address seems to me a bit unspecified in > > the context of multicast. > > Well, because we would be defining Group ID as a group address. "overlay > address" is any value in the address space of the overlay. > ok, I understand. Thus, "A Group-ID is information that uniquely identifies a group within a given overlay." > > > Could you explain in more detail the problem with the current text? > > > Are you saying there are instances where the groupId isn't the root > > > of the tree? > > > > > Yes, one example for this is CAN multicast. The group address in CAN > > is used to address the bootstrap peer. Based on this, the mini CAN > > will be constructed. However, data distribution is based on flooding > > the mini CAN. As far as I understand: Each member of the mini CAN may > > be inherently a source. > > > > Another approach is the bidirectional shared distribution tree, which > > we sketched in Chicago > > http://www.ietf.org/proceedings/07jul/slides/SAMRG-3.pdf (for the > > paper cf. http://www.realmv6.org/bib/ws-buode-07.html) and elaborate > > at the moment. > > I was trying to avoid rendezvous schemes where a rendezvous server > manages the tree, since I don't think it scales. That is why I focused > on the group address being the root address of the tree. > > We could say that GroupId represents the address in the overlay to which > join messages are propagated. This includes models where the GroupID is > the root of the tree, or is a bootstrap or rendezvous point. > Yes, but one has to adjust all messages, like leave, heartbeat ... correspondingly. Maybe one should add a terminology section, which explains general terms. > In reviewing the slides on the shared distribution tree, I guess you are > refering to the IMG ids. I don't see that these are equivalent to > GroupIds since a given tree could have multiple IMG ids, one for each > network domain it has receivers/senders on. If I understand the slides > correctly. > The IMG ids represent the address of the IMG within the overlay (Peer-ID). You are right, these ids don't correspond to group-IDs. The group-ID is used to establish states in the underlying overlay multicast routing protocol. > Also are you thinking about making your scheme overlay agnostic? > Yes, the IMG function is independent of the underlying ALM routing protocol. > Do you have any other suggestions for changes to this document? > * Should we really predefine, that the inter-region connection is implemented by AMT? As far as I understand the draft, it provides a common set of messages to establish the overlay distribution on the one hand and to incorporate native multicast regions on the other hand. Maybe we can say, that AMT is one (mandatory?) option. * I'm a bit confused about the sentence in the abstract: "We use AMT [...] to connect peers in ALM [...] regions with peers in native multicast regions." The term "peer" implies that the system participates in the overlay and provides routing services. Thus, a peer is connected with the overlay. Or do you mean a native multicast client equipped with a JoinViaAMTGateway function? * In general, it would be helpful to sketch the scenario: Does the SAM overlay protocol connect (overlay) peers with native multicast clients which are not aware of the overlay? Thanks matthias -- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik :. link-lab :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 Berlin :. Germany, mailto:waehlisch@ieee.org :. Germany, mailto:mw@link-lab.net :. http://home.fhtw-berlin.de/~mw :. http://www.link-lab.net :. :. FU Berlin, Inst. Informatik, Berlin, Germany http://www.mi.fu-berlin.de _______________________________________________ SAM mailing list SAM@ietf.org https://www.ietf.org/mailman/listinfo/sam