p2psp team mailing list archive

[Vicente Gonzalez <vicente.gonzalez.ruiz@xxxxxxxxx>]

Hi again,

forget my reasoning about that the problem only happens with SYMRP NATs.
You are right. PRCN also will generate problems because the [hello]s from
the peers that are behind a SYMRP NAT will be blocked by the PRCN.

Regards,
Vi.

On Thu, Aug 20, 2015 at 12:00 AM Vicente Gonzalez <
vicente.gonzalez.ruiz@xxxxxxxxx> wrote:

> On Wed, Aug 19, 2015 at 3:27 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:
>
>> Hi Vicente,
>>
>>
>> On 08/19/2015 12:09 PM, Vicente Gonzalez wrote:
>>
>>
>>
>>>
>>> I tested the mobile internet, and apparently it implements a cone NAT
>>> (probably a PRCN) so it has the same source port for every destination
>>> endpoint.
>>>
>>
>> This result has been surprising for me, but your are right. It seems that
>> most mobile ISP uses a PRCN. I have run the test on my wife's network
>> (Vodafone) and this is the result:
>>
>> **********************
>>
>> ...
>> **********************
>>
>> Thanks for the results. So mobile networks seem to be well suited for P2P
>> software, though many providers prohibit those applications. :)
>>
>
> Yes, that seems to be. It a nice find :-)
>
> The other day we also did some experiment transmitting (large) echo ICMP
> packets between two mobiles in the same (mobile) network (I believe that it
> was Pepephone) and the ISP was not aware of the bandwidth consumption. If
> this also happens with UDP datagrams, this means that we could run the
> P2PSP for free :-)
>
>
>>
>>
>> No, I can't imagine any other technique that could help with dealing with
>> random-SYM NATs. Sorry. Maybe, some kind of try-and-if-it-fails-try-again
>> method :-/
>>
>> Ok, this is implemented by the incorporation retry after a timeout.
>>
>
> Yes, I have already seen that in your documentation. Thanks!
>
>
>> Hopefully those NATs won't get implemented too often.
>> And I am also anxious to see P2P possibilities when IPv6 becomes more
>> mainstream, because address translation would not be needed anymore.
>>
>
> That's true. However, IPv6 has been coming for 20 years ... and I think
> that  NATs and firewalls will be used in the future.
>
>
>>
>>
>>
>> On 08/19/2015 03:01 PM, Vicente Gonzalez wrote:
>>
>> But there is still  something that is not totally clear for me. You
>> comment in [1] that when a burst of three UDP datagrams is sent from one
>> entity to another, you represent this by two consecutive arrows. That's OK,
>> however, why some times the arrows have the same direction and other times
>> the opposite direction (I don't understand well you explanation).
>>
>> The second arrow in the opposite direction symbolizes the acknowledge
>> message back to the sender.
>>
>
> OK.
>
>
>> Because UDP is unreliable, a message from a peer is sent repeatedly
>> (every second) until an acknowledge message (exactly the same data) is sent
>> back (so two messages in opposing directions).
>> To reduce load on the splitter, it does not have an extra thread
>> dedicated to send messages continuously, and instead just sends a message
>> several times, without waiting for acknowledge (so two or more messages in
>> the same direction).
>>
>
> Which is the time between two consecutive messages?
>
>
>> Thanks for this hint. Maybe it is better to show just one arrow in the
>> diagrams, and explain the details about message sending from peers and from
>> the splitter in the text?
>>
>
> I think so.
>
>
>>
>> Just a random thought: Currently each peer sends chunks to its peers one
>> after another, in a round-robin style. This means that if there is one peer
>> with random source allocation (SYMRP) in the team, another peer with
>> port-restricted NAT cannot join the team at all (or vice versa) because it
>> fails to connect to one peer.
>>
>
> Let's see if I have understood well your example. You mean that in the
> team there is already a peer that is behind a SYMRP NAT? Yes, this can
> happen if this is the first and the only SYMRP NATted peer of the team.
> Next, a new peer arrives and try to join the team, and this peer is behind
> a PRCN. I don't see any problem with this configuration because the new
> peer should receive the hello replies from the whole team. I think that the
> problem will arise if the new peer is behind a SYMRP NAT device. Or I am
> missing something ...
>
>
>> A complicated solution (maybe for another GSoC or so) could be to have
>> SYMRP peers only connect to peers behind FCN or RCN NATs, and ensure by a
>> special algorithm that network load is distributed equally between the
>> peers. Though I do not know if this is possible and if it has implications
>> on security (DoS attacks could be easier).
>>
>
> We are analysing the possibilities of clustering to cope with these
> situations. For example, if there are several peers behind a SYMRP NAT, it
> could be advantageous to create a local team behind that NAT, only for
> those peers (to achieve this configuration, a public peer should send its
> code-stream to the local splitter, of course).
>
> Good night!
> Vi.
>
>
>>
>> Regards,
>> Max
>>
>>
>> [1] https://github.com/jellysheep/p2psp/blob/nts_doc/doc/NAT_traversal.md
>>
>> --
> --
> 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