use observed RTT as starting point for retransmissions
[oweals/gnunet.git] / src / cadet / TODO
1 - URGENT: Congestion/flow control (CHANNEL):
2   + estimate max bandwidth using bursts and use to for CONGESTION CONTROL!
3    (and figure out how/where to use this!)
4   + figure out flow control without ACKs (unreliable traffic!)
5
6 - HIGH: revisit handling of 'unbuffered' traffic! (CHANNEL/TUNNEL)
7         (need to push down through tunnel into connection selection);
8         At Tunnel-level, try to create connections that match channel
9         preferences (buffered/unbuffered) and select connections for
10         channel traffic that match channel preferences.
11         BUT: not sure this is ideal, discloses traffic type to
12         routers. We don't want that! (Maybe revise decision to do this?)
13
14 - HIGH: revisit handling of 'buffered' traffic: 4 is a rather small buffer; (CHANNEL)
15         maybe reserve more bits in 'options' to allow for buffer size control?
16         Or: maybe even better, calculated required buffer size based on latency
17         and throughput (and available memory)
18
19 - HIGH: if we receive BROKEN messages, cut down corresponding PATH (up to the
20         point of breakage) as well as connection/route (CORE)
21
22 - OPTIMIZATION: proper connection evaluation during connection management:
23   + PATHS: path desirability score calculations are not done
24   + TUNNELS:
25     * consider quality of current connection set when deciding
26       how often to do maintenance
27     * interact with PEER to drive DHT GET/PUT operations based
28       on how much we like our connections
29
30
31 - OPTIMIZATION: optimize stopping/restarting DHT search to situations
32   where we actually need it (i.e. not if we have a direct connection,
33   or if we already have plenty of good short ones, or maybe even
34   to take a break if we have some connections and have searched a lot (?)) (PEER)