Subject: Re: [p2prg] New survey draft on P2P group management (fwd)

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 01 Apr 2010 22:51:00 -0700

Hi Erkki,

thanks for your reply ... I would like to add a remark on the document 
focus (see inline).

On 30.03.2010 03:35, Erkki Harjula wrote:

> On 27.3.2010 1:44, Thomas C. Schmidt wrote:

>> In general, I was lost in the document, as it was not clear to me what
>> this actually addresses. You target at "group management" which
>> actually is a core operation for group communication solutions.
>> However, I could not clearly see that you address group communication
>> in the sense, that the communication model you regard and draw
>> examples from actually is in groups (as distinguished from other
>> multiparty approaches like swarm routing or mesh-building techniques
>> ...).
>
> We use the group management as a more general term. The word "group" is
> not restricted to group communication. Grouping can happen on several
> levels. For example:
> * Improving search efficiency, e.g. by grouping overlay peers based on
> the latency between them (for more efficient application-level P2P
> routing). This kind of grouping might not be even visible to the end-users.
> * Grouping of users (or actually their terminals) to communities based
> on the users' interests. This kind of grouping is visible to the end-users.
>

In my perspective, this appears problematic: There are many operations 
that may go under the name of group formation, but still are mainly 
unrelated. To stay with the examples of your draft:

[Mesh Formation:] You group neighbors to which a node is connected in 
order to form a mesh of some characteristic. The objective is 
"gain/sustain connectivity" and the algorithms mainly center around 
topology, efficiency, stability, robustness ... of course, all is 
visible to the user as "quality of service".

[Swarm Organization:] You group peers according to their content & their 
cooperation in sharing. From an arbitrary number of nodes you select 
those that suit your needs in search/download best, but you don't share 
individual application interests (no need to talk to someone specific) 
... of course, all is visible to the user as "quality of 
service/experience".

[Management for Group Applications:] Users / application needs require 
specific group formation (e.g., conferencing, IPTV, gaming, ...). The 
task is to create individual group relations on demand (as we know it 
from Steve) as part of the core application needs ... of course, this is 
also visible to the user as "the communication core of the application".

For these three areas only, tasks, objectives, and operations are 
completely disjoint and incompatible. I cannot see any value in jointly 
discussing them.

>
>> Correspondingly, you present a (somewhat random) collection of Example
>> Solutions in Section 2. These examples are partly from the group
>> communication area, partly they are not. In particular, they seem far
>> from exploring the design space of group management, and do not always
>> represent initial contributions (P2P group management did not start in
>> the year 2003).
>
> We think it would be too difficult for the readers, if we presented all
> 50+ (currently over 60) publications that we surveyed, at least in this
> first version of our draft. Thus, it is practical to pick only a small,
> heterogeneous subset (6 papers) that covers the different categories as
> well as possible, and thus shows how the classification system works.
> (The categorization system attempts to classify all application-level
> P2P grouping systems, but the selected examples do not.)
>

Depending on the subject area you're looking at, there are not 50++ 
different contributions to group management, but only a few (for 
'application group management' I can think of about four). I guess the 
value of such a draft would be to clearly identify what 
ideas/contributions are around and then later present a survey on the 
performance aspects/further analysis that has been presented in the 
literature.

> Moreover, the example publications neither tried to represent the
> initial, nor the 'best' solutions.
>

Well, I would mention a somehow strong opinion on this, both from a 
"research" and a "fairness" point of view. Just because the Web uses IP 
+ TCP, you cannot reference Berners-Lee while introducing TCP/IP. If you 
recap contributions to a field in a survey, you really should give 
credits to the inventors of these ideas and *not* to imitators or random 
users.

Cheers,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °