1. Required Features
Anonym (in der Praxis komplexitätstheoretisch, aber informationstheoretisch sichere Verwendung nicht verbauen)
Synchronized login phases
Dynamic logout (shutdown of computers or off- line phases at any time)
As much P2P as this does not decrease performance too much, e.g., too many messages. One possibility is Dumb Adding Server(s) and dumb login/logout servers.

2. Nice Features
Option for pure P2P as this does have impact on possibility to regulate offering anonymity services.

3. Layout Client Client Collision handling Collision handling Key sync
Round
Round
Adding

4. Adding (Webserver) add(index, msg)
Add msg to the message stored in index "index" (this offers a possibility to number rounds and thereby execute them in parallel)
Not binary, but adding in group size of message
maxIndex()
Retrieve the largest index ever added
get(index)
Retrieve the (added) msg in index "index"

5. One complex or several simple DC-nets?
Do we make resource scheduling part of the DC-net, then we might be able to achieve something like QoS, but the DC-net gets much more complex.
Do we exclude considering resources from the DC-net, then only the OS might provide some QoS by assigning resources.
If we exclude considering resources from the DC-net, the extreme case is that we implement the DC-net strictly sequential wrt rounds, i.e. all actions concern only the current round (and never old rounds or future rounds). This is the option we pursue in the following slides.

6. (no additional headers, data unit is passed unchanged)
Round
Manages rounds
Each round add() is called
Check for new messages (periodically)
Sends a default message (if send() not called)
send(data unit)
received(data unit)
(no additional headers, data unit is passed unchanged)
add(currentRound, data unit)
get(currentRound)

7. Recipient consistency by DC+-net
The implementation does not provide for that each station can finally decide whether the current round was successful in the sense that the message has been transmitted (to all).
The DC+-net provides for detection of inconsistences in the next round, where no message can be transmitted in case in the round before we had an inconsistency.
Therefore, with the DC+-net, the current rounds also concerns the round before.

8. Participant Remembers the own participant flag index
scratch the flag idea. Better: using counter and in case of errors, use a special error recovery round where everyone send his flag as normal message.
Checks for correct participants
Manages participant keys
Login / Logout
send(msg)
received(msg)
participant flags
original message + all participant keys 1
own flag
linear expense is only justified if fault diagnosis is needed;
otherwise, use counter to reduce additional expense from O(n) to O(log n)
send(newMsg)
received(newMsg)

9. Participant – Login / Logout
Login: send “Hello” - message
Content: “Hello” + own key details
Explain : DC+-net secures consistency of broadcast only for those entities, which have exchanged keys (cf. optimistic fair exchange). But after receiving his own hello, the sender of the hello assumes it has been distributed to all participants of te DC+-net, and therefore superposes the keys he knows (assuming others do that as well), so he can check in the next round using the feature of the DC+-net, wheter the hello has been distributed consistently)
After message appeared, client is assigned the next free participant flag index
Sets default message of “Round” layer
Logout: send “Bye” - message
Content: “Bye” + participant flag index
for securing the “Bye” message, it may be necessary to specify the time of leaving in the future (“I will go in 3 rounds”), so the reliable Broadcast feature of the DC+-net takes place for the bye-message as well

10. Collision ALOHA for now Remembers sent msg's Resent after timeout
Later (2009Q1): Collision Resolving
Even later (2009Q2-3): Reservation scheme
Folie 23 DatenSich.
send(msg)
received(msg)
collision counter
original message
send(newMsg)
received(newMsg)

11. Multiple Adding Server
Adding server itself implements “Participant” and “Round” layer (for other adding server)
Client
Client
Collision
Collision
Participant
Participant
...
Round
Round
Adding Server
Other Server
Participant
Participant
Round
Round
Main Adding Server

12. Key Management Global known DH-parameter (p,g)
Secret x and published y (in “Hello” message)
Always use complete key graph
From which number of participants, this becomes more a problem than other protocols based on rather minimalist key graphs?
PRNG for round keys
Individual pairs of clients may share additional keys
Shouldn't be prevented to regain information theoretically security

13. Messages “Hello” - for login “Bye” - for explicit logout
“Serverinformation” - always first message
information about DH-keyparams
timeouts for the rounds
size of each message
“Reserve” - for reservation scheme?

14. Reserved data comes here
Simple Reservation
“Reserve” + number of rounds
If reservation successful, next number of rounds are reserved
Logical
index 23 24 25 26 27 28 29 30 31
Reserve
5 blocks
Reserved data comes here

15. Simple Reservation – Problems
Needs lots of rounds for big data blobs
Dynamic round timeout necessary
Large Overhead when message slightly too big
This happens a lot when forwarding messages with additional layers (Google: “mtu 1492”)
Large Overhead when message tiny (signals)
Optimized for constant bandwidth consumption
Current internet: High bandwidth with volume restricted fares, bursts of data

16. External Reservation
Reserve large chunks in external adding server
Use same participants as for reservation block
prevents any unobservability
how to couple two seperated DC networks?
If this is solved, problem that the 50MB are reliable broadcasted are also solved.
Logical
index 23 24 25 26 27 28 29 30
Reserve
50MB
Adding Server...
(50MB sized
chunk of data)
Clients can submit this immediately after reservation (no need to wait for rounds)