About communication channels

[Julen Bernabé]

Hi all,

I'm currently doing some research on the way SCALE-MAMBA really works, i.e., what TCP/IP protocols are used while the protocol is running. With this in purpose, I deployed a SCALE-MAMBA network for three players. I captured in WireShark all communications done while the execution was in progress and realised the following:

1. In my case, the first starting the execution was player0. While this player was running the execution and the others were offline, player0 sends a huge amount of TCP SYN packets to player1. The response from player1 was the same amount of TCP RST SYN packets telling player1 is not online (that's my assumption).
   • Why did you implement such a number of TCP SYN messages? I suppose there's a good reason...
2. After some seconds player1 starts the execution. Then player0 and player1 finish the TCP Handshake and start some confusing TLSv.1.3 communications. These communications are not TLS Handshakes, as these occur later. Wireshark captured exactly 18 such communication with changing ports.
   • What are those 18 communications that are previous to the TLSv1.3 handshake? Due to the following steps, I think 18 communication channels are being created between player0 and player1.
   • If those communications are channels, why are there 18? Is that a fixed number? Or it grows with the number of players participating in the computation?
3. When the above step is done, player0 and player1 begin the TCP SYN packet sending in order to establish connection with player2. This step is similar to step 1, but with two peers trying to connnect simultaneously.
4. After some time, player2 starts the execution. Then the TCP handshakes with player1 and player2 are finished and (again) the TLS-not-hanshake communications begin. I captured again 18 different communications per player (player0-player2 and player1-player2).
5. When the TLS-not-handshake communications finish (exactly the 18 per communication), the TLSv1.3 handshake begins. At this stage, again, 18 TLS handshakes are performed. This is why I suppose 18 channels are being created.
6. Lastly, the communications begin. At this stage the capture is very tricky and it's hard to know what is happening exactly. I assume the previous channels are being used to perform the circuit evaluation, am I right?

Thanks beforehand, regards

julen

[Nigel Smart]

Hi

Basically each "player" spawns a number of threads. Each thread
has a dedicated TLS channel to the equivalent thread in the other
players. So the number of TLS channels is big. This way the "code"
does not need to worry about what communication should go to
which thread as this is dealt with by the TLS socket connections.
The number of threads depends on various things [what secret sharing
scheme being used, how many offline/online threads you have
configured the system to use, how many ZK threads in the case of
FHE based pre-processing].

Once all this is set up
- And the setup might not be the most efficient way of doing this
stuff [re your points 1->6]. But who cares as its only done once
;-)

For point 6 we now just assume all communications between each
thread of each player just go like they should in the MPC protocol
description. Sometimes [depending on the specific sub-protocol]
this could be a communication from player 1 to players 2->n.
Sometimes it could be all players send to all other players.
Sometimes it could be just two players talk to each other.
Thus at point 6 it all goes a bit weird as you have seen ;-)

One point with 6 is that when we have a round of all talking to
all, we do this in one of two ways
a) All send then all receive
b) Player i sends to players >i, and receives from player <i
then do the others
The reason for doing a is its easier to implement work out
whats going on, but if the messages sent are huge then you
get a block on the communications due to the limits in the OS
[this is a problem when sending big messages consisting of lots
of FHE ciphertexts and what have you]. In this latter case
we switch to mode b of sending.

On a meta level though, 18 does indeed seem a weird number.
Are you sure its 18 channels between each *pair* of players,
and not 18 outgoing per player to all other players?

Nigel

On 20/01/2022 10:01, Julen Bernabé wrote:
> Hi all,
>
> I'm currently doing some research on the way SCALE-MAMBA really works,
> i.e., what TCP/IP protocols are used while the protocol is running. With
> this in purpose, I deployed a SCALE-MAMBA network for three players. I
> captured in WireShark all communications done while the execution was in
> progress and realised the following:
>

> 1. In my case, the first starting the execution was player0. While this

> player was running the execution and the others were offline,
> player0 sends a huge amount of TCP SYN packets to player1. The
> response from player1 was the same amount of TCP RST SYN packets
> telling player1 is not online (that's my assumption).

> * Why did you implement such a number of TCP SYN messages? I

> suppose there's a good reason...

> 2. After some seconds player1 starts the execution. Then player0 and

> player1 finish the TCP Handshake and start some confusing TLSv.1.3
> communications. These communications are not TLS Handshakes, as
> these occur later. Wireshark captured exactly 18 such communication
> with changing ports.

> * What are those 18 communications that are previous to the

> TLSv1.3 handshake? Due to the following steps, I think 18
> communication channels are being created between player0 and
> player1.

> * If those communications are channels, why are there 18? Is that

> a fixed number? Or it grows with the number of players
> participating in the computation?

> 3. When the above step is done, player0 and player1 begin the TCP SYN

> packet sending in order to establish connection with player2. This
> step is similar to step 1, but with two peers trying to connnect
> simultaneously.

> 4. After some time, player2 starts the execution. Then the TCP

> handshakes with player1 and player2 are finished and (again) the
> TLS-not-hanshake communications begin. I captured again 18 different
> communications per player (player0-player2 and player1-player2).

> 5. When the TLS-not-handshake communications finish (exactly the 18 per

> communication), the TLSv1.3 handshake begins. At this stage, again,
> 18 TLS handshakes are performed. This is why I suppose 18 channels
> are being created.

> 6. Lastly, the communications begin. At this stage the capture is very

> tricky and it's hard to know what is happening exactly. I assume the
> previous channels are being used to perform the circuit evaluation,
> am I right?
>
> Thanks beforehand, regards
>
>
> julen
>

> --
> You received this message because you are subscribed to the Google
> Groups "SPDZ/SCALE-MAMBA Discussion Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to spdz+uns...@googlegroups.com
> <mailto:spdz+uns...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/spdz/a02b1d28-b53d-4151-be19-7230ed06490dn%40googlegroups.com
> <https://groups.google.com/d/msgid/spdz/a02b1d28-b53d-4151-be19-7230ed06490dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Julen Bernabé]

Thanks for your quick answer Nigel,

Regarding to your question, I checked the captures again and, to be more precise, the channels (or threads) are deployed as follows:

• player0 uses 18 different ports to create TLS connections with player1. All those connections go to the same port of player1.
• player0 also uses 18 different ports to create TLS connections with player2. All those connections go to the same port of player2.
• player1 uses 18 different ports to create TLS connections with player2. Al thos connections go to the port of player2 used in the previous step.

Therefore, in the end we have 18 TLS connections established per pair. I'm not sure if the connection term I used here is equivalent to your channel concept.

Apart from that, when you say that the set up process is only done once, is it really true? Since steps [1->6] from my email above happened when throwing the instruction:

./Player.x 0 <path/to/program>

and as far as I can tell that command must always be executed if players want to compute. Am I right?

Regards,

Julen