p2psp team mailing list archive

[Ilshat Shakirov <im.shakirov@xxxxxxxxx>]

Hello!,

hey, don't do the X.509 format yet. Sorry, I did not explain myself
> correctly. Let's leave that for the end: you'll only do it if you have
> enough time, ok? For now I'd rather focus on the tests ;)

Ok =)
So the task list for the week looks like:
1. testing both STrPe & STrPe-DS
2. implement expelling mal. peers from the team

Thanks!

2015-07-27 13:04 GMT+05:00 Juan Álvaro Muñoz Naranjo <juanalvaro83@xxxxxxxxx
>:

> Hi Ilshat,
>
> hey, don't do the X.509 format yet. Sorry, I did not explain myself
> correctly. Let's leave that for the end: you'll only do it if you have
> enough time, ok? For now I'd rather focus on the tests ;)
>
> Thx,
>
> Juan
>
> 2015-07-26 22:04 GMT+02:00 Ilshat Shakirov <im.shakirov@xxxxxxxxx>:
>
>> Hello,
>>
>> Here is small status update (by the results of the this week):
>> http://shakirov-dev.blogspot.ru/2015/07/8th-week.html#more
>>
>> Vicente, Juan, thanks for the responses.
>>
>> did you try tools/create_a_team.sh?
>>>
>> Yes, I've tried it, but I faced with problems with Xterm. I've tried to
>> reinstall it, but it didn't help. I will try more.
>>
>> ---
>>
>> Just one thing: when the DS technique is completed we'll send the public
>>> key under a X.509 certificate format. Ideally this certificate should be
>>> signed by a trusted certificate authority and contain information about the
>>> organization managing the splitter to offer some degree of trust.
>>>
>> It's ok. To be honest I've never do this before, so Ill google it.
>>
>> Regarding of the experiments: ll try to perform it as you described.
>>
>> So my tasks for 9th week:
>> 1. Sending keys with X.509 format
>> 2. Perform tests for the STrPe technique.
>>
>> Also, I wanted to develop heuristic for the excluding malicious peers
>> from the team based on the all the team (not only trusted peers). Do you
>> have any ideas? I think about smth like: 'exclude peer if more than x% of
>> the team marked it as malicious'. Also, we can assign 'reputation' to each
>> peer, so some peers will have more influence on the decision of excluding
>> peer. What do you think?
>>
>> Thanks! =)
>>
>>
>> 2015-07-23 2:01 GMT+05:00 Juan Álvaro Muñoz Naranjo <
>> juanalvaro83@xxxxxxxxx>:
>>
>>> Hi Ilshat,
>>>
>>> first of all thanks for your update, it was very interesting. Just one
>>> thing: when the DS technique is completed we'll send the public key under a
>>> X.509 certificate format. Ideally this certificate should be signed by a
>>> trusted certificate authority and contain information about the
>>> organization managing the splitter to offer some degree of trust. The
>>> certificate might even be distributed with the software, or be given by the
>>> web page if we were in a web player with WebRTC. Otherwise the attacker
>>> might send its own public key to the peers impersonating the splitter. But
>>> for now it is ok like that.
>>>
>>> Now, let's get to the point. How to run the experiments. Vicente already
>>> suggested the use of tools/create_a_team.sh in a previous message (thank
>>> you Vicente!). Also, Cristóbal suggests this:
>>> https://github.com/cristobalmedinalopez/p2psp-chunk-scheduling/blob/master/tools/run_experiment.sh
>>> These solutions are for experiments in one machine of course, which is
>>> enough for us. If you need more peers you should be able to combine several
>>> machines by running one script per machine. Of course, we're interested in
>>> seeing how peers' buffers are filled with chunks and not in video playback:
>>> as you can see, both scripts send the video signal to /dev/null.
>>>
>>> Which experiment to run? We propose the following: we're interested in
>>> average expulsion times for an attacker, and if all of them are expulsed
>>> after a given time. Also, the average percentage of gaps in the peers'
>>> buffers (so we can see if playback is possible in presence of attackers and
>>> after how long). I think you should measure time in terms of sending rounds
>>> (you know, one round would be the splitter sending one chunk to every
>>> member of the team).
>>>
>>> So, let's say that you have a team of 100 peers. From that team, a
>>> percentage of peers will be malicious: 1%, 10%, 25%, 50%. I imagine a plot
>>> in which the X axis is time (number of rounds) and in which we depict:
>>> number of remaining malicious peers in the team (because some of them will
>>> be expulsed) and average filling of peers' buffers. Ideally, as the number
>>> of remaining malicious peers decreases the filling of buffers should
>>> increase.
>>>
>>> Showing the number of complains from peers in the first technique would
>>> be also interesting.
>>>
>>> Another thing to measure would be the percentage of bandwidth used for
>>> real multimedia data (this is, how many bytes from the total are really
>>> used for transmitting the video). You can compare the baseline (no security
>>> measures, just plain video without malicious attackers) against both
>>> techniques.
>>>
>>> So, for running these experiments you'll need to decide which
>>> information you want to store from each peer (buffer filling percentage at
>>> each iteration, how many malicious peers at each iteration, how many bytes
>>> were sent and how many of them were used for video, how many complains
>>> arrived to the splitter in every iteration). Am I forgetting anything?
>>>
>>> My suggestion is run the experiment for the first technique and see how
>>> it goes. Make sure to run the experiment more than once, say 5 times, and
>>> then get the average of them all.
>>>
>>> Good work,
>>>
>>> Juan
>>>
>>> 2015-07-21 20:06 GMT+02:00 Vicente Gonzalez <
>>> vicente.gonzalez.ruiz@xxxxxxxxx>:
>>>
>>>> Hi Ilshat,
>>>>
>>>> did you try tools/create_a_team.sh?
>>>>
>>>> (I tested to run up to 100 peers in my 8HG Mac machine)
>>>>
>>>> Regards,
>>>> Vi.
>>>>
>>>>
>>>> On Sun, Jul 19, 2015 at 8:36 PM Ilshat Shakirov <im.shakirov@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Hello!,
>>>>>
>>>>> Sorry for the long delay.
>>>>>
>>>>> Here is status update about CIS of rules project:
>>>>> http://shakirov-dev.blogspot.ru/2015/07/5-6-7-week.html
>>>>>
>>>>> Also, I need some help with testing a big (ie, 20 peers) p2psp-teams.
>>>>> I want solution that allows to reproduce testing experiments easily. So the
>>>>> commenting lines (to remove need in running vlc) is not suitable for this.
>>>>> I've wrote simple script which runs several peers (in one machine) and
>>>>> here is result
>>>>> <https://www.evernote.com/shard/s427/sh/0b070670-8de9-4a61-acec-562035cfc3ef/7403917d3ca736eea6d60da8ba23543b>.
>>>>> I think it's quite hard to understand smth in this (and reproduce). So,
>>>>> what is the best solution for testing p2psp-teams and gather some stats?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> 2015-06-25 16:13 GMT+05:00 Vicente Gonzalez <
>>>>> vicente.gonzalez.ruiz@xxxxxxxxx>:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 24, 2015 at 5:48 PM L.G.Casado <leo@xxxxxx> wrote:
>>>>>>
>>>>>>>  Hi all,
>>>>>>>
>>>>>>> El mié, 24-06-2015 a las 16:44 +0500, Ilshat Shakirov escribió:
>>>>>>>
>>>>>>> Ok; Is there any option run peer without running a player? I'm going
>>>>>>> to run all peers in one local machine, is it right?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> At this moment, the easiest way to test a lot of peers in one machine
>>>>>> is to connect to each peer a NetCat client [
>>>>>> http://netcat.sourceforge.net/]. It is not the most efficient
>>>>>> solution, but you should be able to run hundreds of peers in a 8GB machine.
>>>>>> However, is quite simple to avoid sending the stream in each peer. Just
>>>>>> comment (temporally) the code that feeds the player.
>>>>>>
>>>>>> Regards,
>>>>>> Vi.
>>>>>> --
>>>>>> --
>>>>>> Vicente González Ruiz
>>>>>> Depto de Informática
>>>>>> Escuela Técnica Superior de Ingeniería
>>>>>> Universidad de Almería
>>>>>>
>>>>>> Carretera Sacramento S/N
>>>>>> 04120, La Cañada de San Urbano
>>>>>> Almería, España
>>>>>>
>>>>>> e-mail: vruiz@xxxxxx
>>>>>> http://www.ual.es/~vruiz
>>>>>> tel: +34 950 015711
>>>>>> fax: +34 950 015486
>>>>>>
>>>>>
>>>>> --
>>>> --
>>>> Vicente González Ruiz
>>>> Depto de Informática
>>>> Escuela Técnica Superior de Ingeniería
>>>> Universidad de Almería
>>>>
>>>> Carretera Sacramento S/N
>>>> 04120, La Cañada de San Urbano
>>>> Almería, España
>>>>
>>>> e-mail: vruiz@xxxxxx
>>>> http://www.ual.es/~vruiz
>>>> tel: +34 950 015711
>>>> fax: +34 950 015486
>>>>
>>>
>>>
>>
>