aboutsummaryrefslogtreecommitdiff
path: root/src/cadet/TODO
blob: 317695a5ba8e6c9ae465faa5fb9c4b7bcc236964 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
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)