[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] [gnunet] branch master updated: note on BDP

From: gnunet
Subject: [GNUnet-SVN] [gnunet] branch master updated: note on BDP
Date: Sun, 09 Jun 2019 18:42:07 +0200

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository gnunet.

The following commit(s) were added to refs/heads/master by this push:
     new 83df7ce4c note on BDP
83df7ce4c is described below

commit 83df7ce4c06542108552a5845252ce8900e4be0e
Author: Christian Grothoff <address@hidden>
AuthorDate: Sun Jun 9 18:41:21 2019 +0200

    note on BDP
 src/transport/gnunet-service-tng.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/transport/gnunet-service-tng.c 
index bb477fc1e..ce16c1541 100644
--- a/src/transport/gnunet-service-tng.c
+++ b/src/transport/gnunet-service-tng.c
@@ -73,6 +73,9 @@
  *   and high-latency links *if* we have the RAM [GOODPUT / utilization / 
  * - Set last_window_consum_limit promise properly based on
  *   latency and bandwidth of the respective connection [GOODPUT / utilization 
/ stalls]
+ * - Need to track total bandwidth per VirtualLink and adjust how frequently
+ *   we send FC messages based on bandwidth-delay-product (and relation
+ *   to the window size!). See OPTIMIZE-FC-BDP.
  * Design realizations / discussion:
  * - communicators do flow control by calling MQ "notify sent"
@@ -4794,11 +4797,14 @@ consider_sending_fc (void *cls)
   struct GNUNET_TIME_Relative rtt;
   duration = GNUNET_TIME_absolute_get_duration (vl->last_fc_transmission);
-  /* FIXME: decide sane criteria on when to do this, instead of doing
+  /* OPTIMIZE-FC-BDP: decide sane criteria on when to do this, instead of doing
      it always! */
   /* For example, we should probably ONLY do this if a bit more than
      an RTT has passed, or if the window changed "significantly" since
-     then. See vl->last_fc_rtt! */
+     then. See vl->last_fc_rtt! NOTE: to do this properly, we also
+     need an estimate for the bandwidth-delay-product for the entire
+     VL, as that determines "significantly". We have the delay, but
+     the bandwidth statistics need to be added for the VL!*/
   (void) duration;
@@ -4827,6 +4833,7 @@ consider_sending_fc (void *cls)
+    /* OPTIMIZE-FC-BDP: rtt is not ideal, we can do better! */
     vl->last_fc_rtt = rtt;
   if (NULL != vl->fc_retransmit_task)

To stop receiving notification emails like this one, please contact

reply via email to

[Prev in Thread] Current Thread [Next in Thread]