p2psp team mailing list archive

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

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