p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

On 08/20/2015 12:00 AM, Vicente Gonzalez wrote:
> 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 :-)
Haha this is great. :D Sometimes also DNS requests (or just any UDP
packet over port 53) is not counting for bandwidth or can traverse
firewalls.

>  
>
>     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.
Yes, that's true, at least for security reasons.

>  
>
>     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?
Currently a message is sent 3 times without a pause in between. This
avoids blocking the splitter (as would be possible when waiting e.g. 1ms
between each message), but could lead to network congestion and a higher
packet loss.

>  
>
>     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).
Ah, now I remember the paragraphs about this technique in the paper.
Sadly when clustering, the splitter has more load as it sends all data
once to each cluster.

> Good night!
> Vi.
Thanks. :)

On 08/20/2015 12:15 AM, Vicente Gonzalez wrote:
> 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.
Exactly, this is what I was thinking of.


Now I finally finished coding, with implementing the reporting of
currently allocated source ports of incorporated peers behind SYMSP NATs.
Today I would like to read through the NTS code again and clean it up,
add comments. For this I have another question about logging and
verbosity: It seems from the P2PSP code that sometimes 'std.stdout',
'print()' and '_print_' is used, debug messages are shown if '__debug__'
is set, and some messages are colorized.
Is there some preferred output method, and coloring scheme? Then I will
apply this to the NTS code as well.

Overnight I will be running final test runs. Are there special
networking conditions (delay, jitter, loss rate) you would like to have
tested? I will probably configure 30ms delay ±5ms jitter and 1% packet
loss (comparable to my home internet), and maybe a harder condition like
10ms delay ±5ms jitter and 10% packet loss to compare.
Then tomorrow morning I will add the result tables to the documentation,
and send pull requests for the nts and the nts_doc branch, so you can
look through it tomorrow before merging. Is this ok for you?

Regards,
Max