p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

On 03.07.2015 16:27, Vicente Gonzalez wrote:
>
>     Exactly. It would be great having a local source server (on the
>     host or on a virtual machine), to not strain your public server
>     and have a reliable source (on the university's network the
>     connection frequently drops, which alters test results).
>     Do you just need the VLC command, or do you have to run Icecast as
>     well?
>
>
> Hi,
>
> both (VLC and Icecast) can be used as a source. See:
>
> http://slides.p2psp.org/Elche-2015/indexse11.html#x29-2500011
>
> In the point 6, there is an example of using VLC as a source. However,
> Icecast is more reliable and it's configuration (at least in a Linux
> host) is really easy.
Thanks for the link. I had to reset my VLC settings, as somehow the
splitter could not read the stream header from VLC (could be some high
cache value that I set for smooth streaming). Now it is working, and I
added the local source to the test script. Note that it now requires the
video file in the working directory, though now does not need an
internet connection anymore.

Taking a few ideas from this paper [1], I added subtypes of the
symmetric NAT type depending on the public source port allocation (port
preservation (SYMPP), sequential port allocation (SYMSP), or random port
allocation (SYMRP)) to the documentation and the script. I added a
result table below, but have to recheck the values to be certain about
the results (the table is not symmetric, I marked the odd results in bold).
This implementation of the symmetric NAT subtypes is to determine if the
(now following) NTS implementation for symmetric NATs works.
An algorithm I would suggest to the P2PSP protocol is to determine if
the NAT is a "port preserving symmetric NAT", i.e. the public source
port is the same as the source port of the local host behind the NAT
(which can easily be determined). Then the only case where a connection
cannot be established would be with two symmetric NATs with random port
allocation, or with sequential allocation and a "port stepsize" greater
than 1 (which seems not supported by the P2PSP algorithms).

Regards,
Max

[1] https://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt

Results for different symmetric NAT subtypes:

Splitter_NTS, Monitor_NTS, Peer_NTS (branch nts, commit 0595dc3):

Peer1\2 | fcn   | rcn   | prcn  | symsp | sympp | symrp   
========================================================
fcn     | yes   | yes   | yes   | no    | no    | yes
rcn     | yes   | yes   | yes   | no    | no    | yes
prcn    | yes   | yes   | yes   | no    | *no*    | no
symsp   | no    | no    | no    | no    | no    | no
sympp   | no    | no    | *yes*   | no    | no    | no
symrp   | yes   | yes   | no    | no    | no    | no