Subject: Re: [SAM] preliminary agenda for SAM RG meeting at IETF 66

From: Xiaoming Fu <[email-masked]>
Date: Thu, 13 Jul 2006 07:32:33 -0400

Hi all,

Before John uploads the presentation slides in 
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66,
a copy for draft-lei-samrg-dmmp-00.txt slides is available in
http://user.informatik.uni-goettingen.de/~fu/omcast/draft-lei-samrg-dmmp-00_IETF66.ppt
Your suggestions and comments are very appreciated.

Look forward to seeing you soon.
Xiaoming

John Buford wrote:
> Here is our first pass at a meeting agenda
> for the meeting at IETF 66. If you have suggestions 
> on the agenda or another contribution you would like
> to present, please send to mail list 
> or chairs.
> 
> John Buford & Jeremy Mineweaster
> 
> ==========================================
> Agenda for SAM RG meeting at IETF-66
> Thursday July 13, 2006 9am - 11:30pm
> 
> 0:00 Welcome (J. Buford, J. Mineweaser)
> 
> 0:05 Agenda bash (J. Buford, J. Mineweaser)
> 
> 0:10 Summary of ALM, OM, and Hybrid systems (J. Buford)
> 
> 0:40 Requirements for Scalable Adaptive Multicast 
>      Framework in Non-GIG Networks (Y. Imai, N.Kawaguchi)
>      draft-muramoto-irtf-sam-generic-require-00.txt
>       
> 1:20 Introduction to the Global Information Grid (GIG) and 
>       key GIG challenges (J. Mineweaser)
> 
> 1:50 DMMP: Dynamic Mesh-based Overlay Multicast Protocol (X. Fu)
>     draft-lei-samrg-dmmp-00.txt
> 
> 2:10 SAMRG Work Plan and Meeting Plan (J. Buford, J. Mineweaser)
> 
> 2:20 Open discussion
> 
> 2:30 Close of meeting
> 
> _______________________________________________
> SAM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sam

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

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 14 Jul 2006 10:18:54 +0900

Dear Xiaoming Fu,

As already pointed out in the session, it was not clear what problem
your scheme is trying to solve. As we know, there is no one size fits
all solutions. Then, we need to sort out;

what are the list of problems we want to tackle

and

what are proper approaches to each of these problems.

Regards

Xiaoming Fu wrote:
>> for the meeting at IETF 66. If you have suggestions on the agenda or 
>> another contribution you would like
>> to present, please send to mail list or chairs.
>>
>> 0:40 Requirements for Scalable Adaptive Multicast      Framework in 
>> Non-GIG Networks (Y. Imai, N.Kawaguchi)

---

From: "Yuji -UG- Imai" <[email-masked]>
Date: Fri, 14 Jul 2006 13:35:40 +0900

Hi, Yangwoo.

  In his presentation, he could not emphasized the point you described,
but reading Motivation slide (Page 4) and Internet Draft, you can see much
more detailed explanation the target he want to solve and why these area
cannot be solved by any other ASM, OM scheme at tirst part of the draft.
(20 minutes is tooshort to explain overall infos.... I made mistake in my
presentation this time.)

The targets are

- To support real-time media streaming applications, optimizing both
the available bandwidth and the delay for group members
- To support large-scale groups without relying on any predetermined
intermediate nodes, namely the overlay multicast is solely constructed
by end hosts

That seems not enough if they start to make system but, for me, good enough to
start to try novel approach of SAM and investigation.

So generally speaking, IRTF real meeting is too much short. We have to spent
more to read and write materials that we can exchange the idea each other.

And my impression for DMMP are

 - From operatinal view, who volunteerly settle the high capacity node on
good point of the network and let other use it for DMMP?  For me, that may
become obstacle for "service connectivity cycle".

- From developper and poerator's view, the system looks so complicated that
logic the sytem has and whole DMMP network is not developed by reasonable
cost. Especially, distributed debugging of supernode and end node behavior
is quite difficult, it is sama as experienced in deploying group
multicast scheme.

But analysis of existing ALM, OM and DMMP scheme is valuable.

So, I want others take a look of their draft.
--
ug

-- 
ug

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 14 Jul 2006 14:17:31 +0900

Dear UG,

I also presumed that their draft includes such an information.
The issue that I wanted to point out in the previous mail was;

* Application scenarios and requirements are well presented
in previous presentations

and

* DMMP is presented in a way how it satisfies one (or more)
scenarios or requirements well.

In that sense, today's session was somewhat hard to follow up.
Anyway it was a really really good start though. :-)

I will send more detailed comments on DMMP and others later
if time permits.

Regards

---

From: Jun Lei <[email-masked]>
Date: Mon, 17 Jul 2006 17:05:26 +0200

Dear Yangwoo, all:

      Thank you for your comments. The slides presented in IETF66 might 
not have touched at your expections. However, the proposed DMMP has 
basically solved the following requirements:

1. Multicast capability, either one-to-many, or many-to-many
2. Scalability requirements: DMMP is capable of supporting thousands of 
group per session
3. Adaptive requirements:
    * DMMP is able to handle dynamic network changes and group changes.
    * Latency and redundancy control are also considered in DMMP
4. Security aspects are considered in DMMP in terms of its group member 
management and AAA-related issues.

Detailed explanation could be found in the draft.

hi, UG:
     To the aspect of "service connectivity cycle", super nodes of DMMP 
are selected according to the following standard:
     Super nodes which are able to and willing to make some 
contributions to the network are likely to get better performances.

     Users don't care about exact operations. If they could get better 
services, they have no reason to reject being the super nodes.

Cheers

Jun

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

---

From: "Yuji -UG- Imai" <[email-masked]>
Date: Tue, 18 Jul 2006 02:28:15 +0900

Hi, Jun Lei,

 Super node approach is now success. Skype is the best example I think.
However, as nodes increase so much rapidly, there are someone who dislike
to make their nodes be a supernode. Actually, I know several who experienced
their node EVENTUALLY elected as super nodes and load increased so much
that they cannot do ordinal work any more. As protocol and behavior of skype
was kept secret, in order to stop being supernode they must stop skype program.

Recently, skype was reverse-engineered.
http://www.secdev.org/conf/skype_BHEU06.handout.pdf

Then some start fake of skype that never be a supernode.
http://www.voipwiki.com/blog/?p=16

Regarding this story, to make supernode method be successful and happy
for all, we must make some social mechanism that user appreciate to make
their machine be a supernode. Is it possible? To tell the truth, I am
pessimistic to find the way.

Do you have any idea to solve that?
--
ug

-- 
ug

---

From: "Jun Lei" <[email-masked]>
Date: Mon, 17 Jul 2006 21:04:09 +0200

Dear UG:
        Thank you for your instant comments.
        See inline.
----- Original Message ----- 
From: "Yuji -UG- Imai" <[email-masked]>
To: "Jun Lei" <[email-masked]>
Cc: "Yangwoo Ko" <[email-masked]>; <[email-masked]>
Sent: Monday, July 17, 2006 7:28 PM
Subject: Re: [SAM] preliminary agenda for SAM RG meeting at IETF 66

> pessimistic to find the way.

Yeah, it is really a problem. DMMP has an assumption that a small number of 
users are able to and willing to act as super nodes. Otherwise, we could 
only designate some routers as super nodes. Currently, we assume that users 
would not reject being super nodes because super nodes could receive better 
services.

If any is novated, we would notify you asap.

Cheers
Jun

---

From: "Yuji -UG- Imai" <[email-masked]>
Date: Tue, 18 Jul 2006 06:17:03 +0900

Hi, Jun Lei and all.

  I, in my mind, define this is categorized in "Selfishness v.s.
Fairness" problem.

  For the system, some or all must collaborate voluntary, impartially
and faithfully.
In old good days of the Internet, it could be. However, there are
several systems,
may be numerous, that break the balance intentionally. That's what I want to
point out by my slide of previous presentation in Montreal.

  It may be so broadly make impact for efficients that being out of
scope only of the
SAM-RG. But we MUST overcome this problem somehow.
--
ug

-- 
ug

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 18 Jul 2006 11:02:37 +0900

Though there have been several proposals to overcome selfishness
in peer networks (especially in ad hoc routing and p2p area), I
have not yet been convinced that they are really enough. I do not
think that overcoming this should be one of the main goals of SAM
RG, it worths considering as part of design constraints.

In addition to this I want to point out that UG's "Selfishness
vs. Fairness" may be somewhat misleading. I admit that selfishness
may yield unfairness. But the better way to understand and tackle
this issue is how to yield fairness from selfish reactions of
participants. For example, one of typical questions is how to make
the incentive for serving  as a supernode big enough so that
equilibrium can be obtained as soon as possible.

Regards

Yuji -UG- Imai wrote:
>> >> >> but reading Motivation slide (Page 4) and Internet Draft, you 
>> can see
>> >> >> much
>> >> >> (20 minutes is tooshort to explain overall infos.... I made 
>> mistake in
>> >> >> my
>> >> >> presentation this time.)
>> >> >>
>> >> >> The targets are
>> >> >>
>> >> >> That seems not enough if they start to make system but, for me, 
>> good
>> >> >> enough to
>> >> >> So generally speaking, IRTF real meeting is too much short. We 
>> have to
>> >> >> spent
>> >> >> - From operatinal view, who volunteerly settle the high capacity 
>> node
>> >> >> on
>> >> >> good point of the network and let other use it for DMMP?  For 
>> me, that
>> >> >> may
>> >> >> - From developper and poerator's view, the system looks so 
>> complicated
>> >> >> that
>> >> >>> >> for the meeting at IETF 66. If you have suggestions on the 
>> agenda
>> >> >>> >> or
>> Framework
>> >> >>> >> in

---

From: Yuji IMAI <[email-masked]>
Date: Tue, 18 Jul 2006 13:42:10 +0900

Hi, Yangwoo,

Yangwoo Ko wrote:
> vs. Fairness" may be somewhat misleading.

Exactly. In a sense, TCP algorithm behave selfish but achieve fairness.
"Selfish routing" presented ad-hoc meeting in IETF65 conclude in a
certain environment, network organizer keep network not crowded with
clients behave selfish.

How to expressed this problem? Good phrase is needed.
--
ug

> I admit that selfishness
>>> >> >> more detailed explanation the target he want to solve and why 
>>> these
>>> >> >> area
>>> >> >> more to read and write materials that we can exchange the idea 
>>> each
>>> >> >> other.
>>> >> >>
>>> >> >> - From operatinal view, who volunteerly settle the high 
>>> capacity node
>>> >> >> on

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 18 Jul 2006 13:57:21 +0900

> Exactly. In a sense, TCP algorithm behave selfish but achieve fairness.

Yes and No.

TCP achieves fairness so that multiple TCP streams can obtain
roughly same bandwidth. However seen at higher level, an application
can obtain more bandwidth by having multiple TCP streams. In that
sense, we need to consider in what level we are going to achieve
fairness.

> How to expressed this problem? Good phrase is needed.

I want to leave terminology issue to English natives. My
suggestion is that just use "fairness" so that we can open
far more possibilities for cases and solutions.

Regards

(snip)

---

From: Eiichi Muramoto <[email-masked]>
Date: Tue, 18 Jul 2006 14:37:05 +0900

Hello, All

Although I could not catch up with discussion,
I think the word "fairness" is important to make us think varous things.

TCP(TFRC) streams can obtain more bandwidth, when it is relayed.
(A-B-C is better than A-C. B is tcp relay. I think if an application 
 on B receive the stream, it is fare.)

I think the consensus, "what is fare" might be one of the goal of SAM-RG activity,
after we should define and share problems.

Regards,
Eiichi Muramoto.

>(snip)

-----
[email-masked]

---

From: Yuji IMAI <[email-masked]>
Date: Tue, 18 Jul 2006 16:50:38 +0900

Yes, Yangwoo. You are sharp.

> sense, we need to consider in what level we are going to achieve

If we would be able to have SAM framework in future, that must have
abstraction like TCP virtual circuit. In addition, we man have to define
the guideline for application to behave good. Some may say it not enough
because someone in the world break the rule.

I don't have any idea for this result. But fortunately, we still be in
the day of http/tcp without catastrophic bandwidth crash.

> far more possibilities for cases and solutions.

Agree.
--
ug