some more typos and improvments

1 files changed, 32 insertions, 22 deletions

diff --git a/NOTES b/NOTES
index f9c509d..5a48989 100644
--- a/NOTES
+++ b/NOTES
@@ -11,7 +11,8 @@ sender-id/mux:
   number of concurrent virtual connections...
 
   New Idea: don't sub-assign parts of mux but reduce sender-id to 12 bit. This
-  frees up 4 bits for additional signaling.
+  is most probably still enough for very big anycast cluster and frees up 4 bits
+  for additional signaling.
   The new header would look like this:
 
     0                   1                   2                   3
@@ -35,13 +36,18 @@ inline Key-exchange:
   the X flag set.
 
   Idea: use crypto role (server/client, left/right, alice/bob) for addressing
-
   possible adressing scheme:
-
-     role(server,left,alice) -> fe80::xxxx:0:0:1:0/64
-     role(client,right,bob)  -> fe80::xxxx:0:0:0:<mux>/64
-
-      (xxxx is a well known number for SATP, i.e is always '5ADB')
+     role(server,left,alice) -> fe80::xx:xx00:1/64
+     role(client,right,bob)  -> fe80::xx:xx00:<mux>/64
+      (xx:xx is a well known number for SATP, i.e is always '5A:DB'
+       mind IPv6 stateless autoconfiguration will always generate adresses
+       with xx:xx set to FF:FE, Question: what about privacy extension?)
+
+  alternative addressing: make use of the link-local address that is generated
+  by the the OS (which should be the case for any interface with IPv6 enabled)
+  and only add a well known address on one side, the server, (which wouldn't be
+  selected by the automatic address selection algorightm). But in this case the
+  server needs to learn the link-local adresses of the muxes aka clients.
 
   Question: How to handle systems with IPv6 disabled? No inline key-exchange
   support in that case? IPv4 Link-local Adresses only have a /16 range and we
@@ -91,31 +97,35 @@ Packet Handling (Marshal/Unmarshal):
   Header, Payload and Authtag of EncryptedPacket as well as Type and Payload of
   PlainPacket are go slices pointing to the underlaying buffer. The Header of
   EncryptedPacket und Type of PlainPacket have Getter and Setter which directly
-  encode/decode using BigEndian.(Put)?Uint(16|32). All of this shouldn't need any
-  mallocs and would therefor be pretty fast.
-
-  EncryptedPacket has function VerifyAndDecrypt() which takes a PlainPacket to
-  store the result. PlainPacket has a EncryptAndAuthenticate() which takes an
-  EncryptedPacket to store the result. The implicit copy operations of that
-  crypto functions are free because the encrypt/decrypt process needs to read
-  and write the memory anyway and it makes no difference whether the destination
-  is the same or some other memory area.
+  encode/decode using BigEndian.(Put)?Uint(16|32). All of this shouldn't need
+  any mallocs and would therefor be pretty fast.
+
+  EncryptedPacket has a function VerifyAndDecrypt() which takes a PlainPacket to
+  store the result. PlainPacket has a function EncryptAndAuthenticate() which
+  takes an EncryptedPacket to store the result. The implicit copy operations of
+  that crypto functions are free because the encrypt/decrypt process needs to
+  read and write the memory anyway and it makes no difference whether the
+  destination is the same or some other memory area.
+  Both packet types implement the ReaderFrom and WriterTo interface in order
+  to directly read-from/write-to tun/tap device and UDP sockets.
   Conclusion: Any packet handling goroutine holds one EncryptedPacket and one
   PlainPacket.
 
-  Idea: Have NumCPU goroutines for receving and NumCPU goroutines for sending.
+  Idea: Have NumCPU goroutines for receiving and NumCPU goroutines for sending.
 
     Receiving:    UPD   --> verify&decrypt --> tun/tap
     Sendung:    tun/tap -->  encrypt&auth  -->   UDP
 
 
-  Question: How can multiple goroutines listen to multiple UDP sockets but only
-  have the overall system allow only NumCPU packets to be handled at once?
-  And what about the NumCPU goroutines in the other direction?
+  Question: How can multiple goroutines listen to multiple UDP sockets but have
+  the overall system allow only NumCPU packets to be handled at once? There
+  are several cases where the above scheme leads to either to few or too many
+  concurrent operations (a lot of traffic from a single source sent only in one
+  direction vs. all sources send a lot of data in both directions).
 
   different approach:
-    - one goroutine listeing on all udp sockets + tun/tap using select()
-    - when dispatcher gouroutine wakes up it starts upto NumCPU goroutines
+    - one goroutine listening on all udp sockets + tun/tap using select()
+    - when dispatcher gouroutine wakes up it starts up to NumCPU goroutines
       for all the sockets and tun/tap device ready for read.
     - only if all the file descripters returned by select() are assigned to
       a running goroutine the dispatcher goroutine calls select() again.