Subject: Re: [SAM] SAM RG interim meeting results

From: Eiichi Muramoto <[email-masked]>
Date: Tue, 05 Jun 2007 06:32:03 +0900

Dear Jun,

We submitted an ID on this. URL for the software is written.
Comments including the one to correct my English are expected. (^^;

	Title		: Experimental Deployment Method for Router Supported ALM using PlanetLab
	Author(s)	: E. Muramoto, et al.
	Filename	: draft-muramoto-irtf-sam-exp-testbed-00.txt
	Pages		: 12
	Date		: 2007-5-4
	
   This document describes the experiment method of router supported ALM
   using PlanetLab.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muramoto-irtf-sam-exp-testbed-00.txt

Jun Lei wrote:
>Dear Eiichi,
>
>thanks for your message. We are interested in working over PlanetLab. 
>And I agree with you that PlanetLab can be regarded as one of the most 
>promising candidates to test the overlay networks(routing protocols) 
>under the real environment.
>
>Could you please show me some detailed description of your software? I 
>would like to take a look at it.
>
>Thank you anyway
>
>Jun
>> Hello, 
>> 
>> I think that the test bed where overlay was used is profitable for 
>> researchers ( experimenters). The experimenter can construct  his 
>> experiment network on Planetlab momentarily, can bigin the "user-
>> opt-in" experiment freely, and it is possible to stop it safly.
>> 
>> For example, we xcast person can construct IPv6 routing plane
>> on to the planetlab using the "orbit" tunnel(IPv6 over IPv4)
>> and settle l2tp servers on the slice of planetlab for the users.
>> and begin the xcast routing experiment.
>> 
>> Some might think he want to experiment on his hybrid solution 
>> of ALM and IP multicast. He probably make a multicast enable network
>> and settle a ALM-IP multicast-bridge.
>> 
>> Testbed sometimes accelerates the research works.
>> 
>> I think we can discuss about it in this RG. 
>> Do you agree? Any comment?
>> 
>> Best Regards,
>> Eiichi Muramoto.
>> 
>> 
>> Nobuo Kawaguchi wrote:
>> 
>>>Dear SAM-RG members,
>>>
>>>In the last P2PM07 workshop, I had a demonstration
>>>about overlay network on PlanetLab with MyPLC.
>>>The presentation material is
>>>http://www.samrg.org/p2pm07/presentations/XcastOnPlanetLab20070111.pdf
>>>
>>>We are currently planning to open our demonstration softwares.
>>>By using our softwares, one can utilize UML on PlanetLab and
>>>connect UML nodes using UDP tunnel. Our "orbit" software can manage the
>>>configuration of all UDP tunnels from a single conf file.
>>>In the UML node, one can run any Linux binary using usual ethernet
>>>interfaces over virtual links.
>>>In our demonstration, we modified UML kernel to use 
>>>XCAST6(eXplicit Multi-Unicast) so that we can show xcast routing 
>>>over UML nodes.
>>>
>>>Is there any person who are interested to use our software?
>>>We are willing to write a document for interested persons.
>>>
>>>I think, for SAM-RG, PlanetLab is one of the candidate to test the
>>>overlay networks(routing protocols) for real environment.
>>>Our UML trial can regarded as a start point.
>>>We are also planning to write "Internet-Draft" about our overlay
>>>configuration.
>>>
>>>If you have any suggestion about I-D or our softwares,
>>>please let me know.
>>>
>>>Best regards,
>>>Nobuo Kawaguchi
>>>--
>>>Nagoya Univ. 
>>>
>>>
>>>John Buford wrote:
>>>
>>>>Presentations and meeting notes for the Jan 11 interim SAM RG meeting
>>>>are available here:
>>>>
>>>>http://www.samrg.org/about/meetings/meetings.html
>>>>(not all slides are available yet, they will be uploaded as they
>>>>become available)
>>>>
>>>>Presentations made at the P2PM07 workshop are available here:
>>>>http://www.samrg.org/p2pm07/program.html
>>>>
>>>>(not all slides are available yet, they will be uploaded as they become
>>>>available)
>>>>
>>>>We are currently planning to hold an RG meeting at IEFT 69 (Chicago).
>>>>
>>>>Minutes from the meeting follow.
>>>>
>>>>===============================================================
>>>>
>>>>
>>>>Meeting Notes
>>>>Scalable Adaptive Multicast RG
>>>>Interim Meeting Jan 11, 2007.
>>>>
>>>>1. John Buford (Panasonic)
>>>>
>>>>Overview of problem statement draft
>>>>and the existing technologies available
>>>>(ALM, Overlay multicast, Proxied overlay
>>>>multicast, tunneling with native multicast
>>>>islands).
>>>>An example architecture and some
>>>>operational scenarios.
>>>>
>>>>1. Jeremy Mineweaser (MIT Lincoln Labs)
>>>>
>>>>Adaptativity depends on suitable metrics
>>>>and ability to collect these metrics in
>>>>real-time and feedback to the network.
>>>>
>>>>
>>>>Discussion:
>>>>
>>>>KA: Do you think adaptive approach is too complex to be worth the benefit?
>>>>JM: remains to be seen
>>>>KA: We don't really have a one-size-fits-all protocol
>>>>
>>>>2. Mark Pullen (GMU)
>>>>
>>>>Unlike commercial ISPs,DoD ISPs have an incentive
>>>>to use multicast to reduce congestion.
>>>>But universal deployment in GIG may not work any better
>>>>than in commercial sector.
>>>>Gaming community can use multicast in different ways
>>>>than DoD since they don't require the real-world fidelity.
>>>>
>>>>In battlefield, reliability and robustness may not be
>>>>fully achievable.
>>>>
>>>>We at GMU have a prototype to manage multicast using
>>>>web services in cooperation with Naval Post-Graduate school.
>>>>
>>>>There is a need for a framework to interoperate
>>>>different mechanisms, a pervasive interoperability should be targeted.
>>>>Need the pieces to interoperate in order to mix and match technologies.
>>>>Would like to see a standardized tunneling mechanism as well.
>>>>Could use the framework for "relative" QoS not absolute QoS.
>>>>Relative QoS is important for military applications.
>>>>
>>>>3. Keith Ross (Polytechnic)
>>>>
>>>>P2P Multicast is an IPTV case study
>>>>There are several success stories: PPLive, Coolstream, ppstream
>>>>200K users at 400-800 kbps for Chinese New Years
>>>>
>>>>What are the challenges?
>>>>- Bandwidth intensive
>>>>- peers dynamic
>>>>- asymetric residential access
>>>>- incentives for redistribution
>>>>- lags among viewers
>>>>- security (pollution, overtaking for DDoS)
>>>>
>>>>Comparison of two Architectures
>>>>- Push, tree-based designs, eg. ESM from CMU
>>>>- Pull, meshed based designs
>>>>  Inspired from BiTorrent
>>>>  But with live streaming
>>>> More successful than ESM
>>>>
>>>>Overview of pull-mesh
>>>>Locate other peers watching same channel
>>>>Establish TCP connection
>>>>Ask neighbors what chunks they have
>>>>Request and receive chunks
>>>>Start media player
>>>>Upload chunks to others
>>>>
>>>>Presents some measurements of download
>>>>vs upload rate for different users
>>>>
>>>>Popular and unpopular channels
>>>>Pull-mesh / IPTV is killer application for multicast
>>>>
>>>>JM: what are limitations?
>>>>KR: free-riding problem, susceptibility to pollution attack
>>>>Audience: what is the performance comparison between pull and push
>>>>KR: coolstreaming paper has analysis that shows the ESM
>>>>   is not good under churn
>>>>JB: what about licensed content?
>>>>KR: yes, content provides can see this as another distribution channel
>>>>
>>>>
>>>>4. Kurt Tutschku (U. Wuerzburg)
>>>>
>>>>Challenges on scalable multicast in overlay with mobile networks
>>>>There are several challenges due to mobile nodes in an overlay
>>>> which translate to problems with overlay multicast with mobile
>>>> nodes
>>>>These problems relate to roaming in the native network,
>>>>node performance capability, variation in network connectivity etc.
>>>>
>>>>
>>>>5. Wenjun Zeng (U. Missouri)
>>>>
>>>>Do you plan to consider reliability, congestion control,
>>>>  etc., in the design?
>>>>Pull vs push is an important distinction, as made by Keith
>>>>Is there a hybrid of pull vs push?
>>>>E.g., tree-bone based approach
>>>>
>>>>6. General Discussion
>>>>
>>>>What about data aggregation for sensor
>>>>data collection (ad hoc wireless networks),
>>>>is there a multicast solution for this case,
>>>>and how does it fit?
>>>>
>>>>The benefits of an overlay approach for launching SAM framework:
>>>>Overlays provide a number of interesting functions including
>>>>search, indexing, relaying, topology characterization, measurement.
>>>>Integrating awareness of native multicast in to the overlay is
>>>>another function like these others that a specific overlay can
>>>>chose to use or not depending on application requirements.
>>>>
>>>>Solutions to the problems of overlays in terms of reliability
>>>>and security can be used for multicast reliability and security
>>>>perhaps.
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>SAM mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/sam
>>>
>>>
>>>_______________________________________________
>>>SAM mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/sam
>> 
>> 
>> -----
>> [email-masked]
>> 
>> _______________________________________________
>> SAM mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/sam
>
>
>-- 
>Jun Lei
>PhD Student
>
>Address:
>Georg-August-Universitaet Goettingen
>Institut fuer Informatik
>Telematics Group
>Lotzestrasse 16-18
>37083 Goettingen
>
>
>Fax: +49 (551) 39-1 44 03
>Tel: +49 (551) 39-1 35 78
>
>Email: [email-masked]

-----
[email-masked]

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

---

From: Scott Boone <[email-masked]>
Date: Mon, 25 Jun 2007 13:59:48 -0700

Has much work been done in the SAM area w.r.t. PIM in IPv6?  My  
current understanding is that the only RP discovery option in IPv6 is  
embedded RP.  This doesn't seem to play at all well with readdressing  
or failovers.  Does anyone have pointers for RP failover work in  
mobile IPv6 networks?  Is this the right group for me to ask this?

Thanks,
Scott

---

From: Stig Venaas <[email-masked]>
Date: Mon, 25 Jun 2007 23:28:04 +0200

Scott Boone wrote:
> Has much work been done in the SAM area w.r.t. PIM in IPv6?  My current 
> understanding is that the only RP discovery option in IPv6 is embedded 
> RP.  This doesn't seem to play at all well with readdressing or 
> failovers.  Does anyone have pointers for RP failover work in mobile 
> IPv6 networks?  Is this the right group for me to ask this?

Embedded-RP is the way to go for interdomain multicast (well for
ASM, for SSM you obviously don't need it), but intradomain you can
use BSR for RP discovery as well.

If you do embedded-RP you cannot change the RP address, but you
could consider anycast with two RPs having the same address. It
would work well together with the mechanism in RFC 4610.

Without RFC 4610 you could make it so that everyone uses the same
RP when it is up, and when it goes down, have everyone move to the
other. You would then lose RP state when switching which is not
good, but ongoing multicast would hopefully be through SPTs, and
not be affected by this.

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Jun 2007 15:25:16 -0700

> use BSR for RP discovery as well.

And for Bidir-PIM for IPv6, you probably don't want to use Embedded- 
RP, or else you could have data triggered DF-election on each link a  
packet is traveling upstream to the RP.

Dino

---

From: Kevin C Almeroth <[email-masked]>
Date: Mon, 25 Jun 2007 18:38:29 -0700 (PDT)

You might also look at:

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13992

On Mon, 25 Jun 2007, Scott Boone wrote:

>> understanding is that the only RP discovery option in IPv6 is embedded RP.
>> This doesn't seem to play at all well with readdressing or failovers.  Does
>> anyone have pointers for RP failover work in mobile IPv6 networks?  Is this
>> the right group for me to ask this?
>>
>> Thanks,
>> Scott
>>