X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;f=src%2Fcadet%2FTODO;h=820efab7a60eb2846548fda764ec709367959f95;hb=0af32e03677ab1c8a819b376c8fa026d0ffa9144;hp=1fc134564848fd55f74e9c187b2489374e5ab5ae;hpb=728df2e4f408bb16c3e15bd7395659d3c9667e82;p=oweals%2Fgnunet.git

diff --git a/src/cadet/TODO b/src/cadet/TODO
index 1fc134564..820efab7a 100644
--- a/src/cadet/TODO
+++ b/src/cadet/TODO
@@ -1,21 +1,14 @@
-- URGENT: implement path desirability calculations (lack of them is confusing!)
-
 - 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.
+        channel traffic that match channel preferences.
+        BUT: not sure this is ideal, discloses traffic type to
+        routers. We don't want that! (Maybe revise decision to do this?)
 
 - 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?
@@ -26,14 +19,7 @@
         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