collect misc. TODO items into one big list
authorChristian Grothoff <christian@grothoff.org>
Sun, 29 Jan 2017 17:52:36 +0000 (18:52 +0100)
committerChristian Grothoff <christian@grothoff.org>
Sun, 29 Jan 2017 17:52:36 +0000 (18:52 +0100)
src/cadet/TODO [new file with mode: 0644]
src/cadet/gnunet-service-cadet-new_core.c

diff --git a/src/cadet/TODO b/src/cadet/TODO
new file mode 100644 (file)
index 0000000..317695a
--- /dev/null
@@ -0,0 +1,44 @@
+- URGENT: Congestion/flow control (CHANNEL):
+  + estimate max bandwidth using bursts and use to for CONGESTION CONTROL!
+   (and figure out how/where to use this!)
+  + calculate current RTT if possible, use that for initial retransmissions
+   (NOTE: needs us to learn which connection the tunnel uses for the message!)
+  + figure out flow control without ACKs (unreliable traffic!)
+
+- HIGH: revisit message buffer, have global buffer instead per-route, but then
+        make sure it is shared fairly across routes and connections (CORE);
+        also, do not buffer if the connection is set to unbuffered!
+
+- HIGH: revisit handling of 'unbuffered' traffic! (CHANNEL/TUNNEL)
+        (need to push down through tunnel into connection selection);
+        At Tunnel-level, try to create connections that match channel
+        preferences (buffered/unbuffered) and select connections for
+         channel traffic that match channel preferences.
+
+- HIGH: revisit handling of 'buffered' traffic: 4 is a rather small buffer; (CHANNEL)
+        maybe reserve more bits in 'options' to allow for buffer size control?
+        Or: maybe even better, calculated required buffer size based on latency
+        and throughput (and available memory)
+
+- HIGH: if we receive BROKEN messages, cut down corresponding PATH (up to the
+        point of breakage) as well as connection/route (CORE)
+
+- OPTIMIZATION: proper connection evaluation during connection management:
+  + PATHS: path desirability score calculations are not done
+  + CONNECTION: keep per-connection performance metrics;
+                in particular, interact with channel (!) to see
+                if we get ACKs indicating successful payload delivery.
+  + TUNNELS:
+    * when managing connections, distinguish those that
+      have (recently) had traffic from those that were
+      never ready (or not recently)
+    * consider quality of current connection set when deciding
+      how often to do maintenance
+    * interact with PEER to drive DHT GET/PUT operations based
+      on how much we like our connections
+
+
+- OPTIMIZATION: optimize stopping/restarting DHT search to situations
+  where we actually need it (i.e. not if we have a direct connection,
+  or if we already have plenty of good short ones, or maybe even
+  to take a break if we have some connections and have searched a lot (?)) (PEER)
index 75a94119ca953e04db5c3db75679cb9296354f2c..b79b87de854c1090399e7b5274550e9a66601a4e 100644 (file)
@@ -47,6 +47,7 @@
 
 /**
  * Number of messages we are willing to buffer per route.
+ * FIXME: have global buffer pool instead!
  */
 #define ROUTE_BUFFER_SIZE 8