All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: [PATCH 2/25]: Avoid accumulation of large send credit
Date: Wed, 21 Mar 2007 18:44:11 +0000	[thread overview]
Message-ID: <200703211844.12007@strip-the-willow> (raw)

[CCID 3]: Avoid accumulation of large send credit

Problem:
--------
 Large backlogs of packets which can be sent immediately currently accumulate
 when (i) the application idles, or (ii) the application emits at a rate slower
 than the allowed rate X/s, or (iii) due to scheduling inaccuracy (resolution
 only up to HZ). The consequence is that a huge burst of packets can be sent
 immediately, which violates the allowed sending rate and can (worst case)
 choke the network.
 NB: Corresponding paragraph on send credits recently added to rfc3448bis

Fix:
----
 Avoid any backlog of sending time which is greater than one whole t_ipi. This
 permits the coarse-granularity bursts mentioned in [RFC 3448, 4.6], but disallows
 the disproportionally large bursts.

 D e t a i l e d   J u s t i f i c a t i o n   [not commit message]
 ------------------------------------------------------------------
 Let t_nom < t_now be such that t_now = t_nom + n*t_ipi + t_r, where
 n is a natural number and t_r < t_ipi. Then 
 
 	t_nom - t_now = - (n*t_ipi + t_r)
 
 First consider n=0: the current packet is sent immediately, and for
 the next one the send time is
 	
 	t_nom'  =  t_nom + t_ipi  =  t_now + (t_ipi - t_r)
 
 Thus the next packet is sent t_r time units earlier. The result is
 burstier traffic, as the inter-packet spacing is reduced; this 
 burstiness is mentioned by [RFC 3448, 4.6]. 
 
 Now consider n=1. This case is illustrated below
 
 	|<----- t_ipi -------->|<-- t_r -->|
 
 	|----------------------|-----------|
 	t_nom                              t_now
 
 Not only can the next packet be sent t_r time units earlier, a third
 packet can additionally be sent at the same time. 
 
 This case can be generalised in that the packet scheduling mechanism
 now acts as a Token Bucket Filter whose bucket size equals n: when
 n=0, a packet can only be sent when the next token arrives. When n>0,
 a burst of n packets can be sent immediately in addition to the tokens
 which arrive with rate rho = 1/t_ipi.
 
 The aim of CCID 3 is an on average smooth traffic with allowed sending
 rate X. The following determines the required bucket size n for the 
 purpose of achieving, over the period of one RTT R, an average allowed
 sending rate X.
 The number of bytes sent during this period is X*R. Tokens arrive with
 rate rho at the bucket, whose size n shall be determined now. Over the
 period of R, the TBF allows s * (n + R * rho) bytes to be sent, since
 each token represents a packet of size s. Hence we have the equation
 
 		s * (n + R * rho) = X * R
 	<=>	n + R/t_ipi	  = X/s * R = R / t_ipi
 
 which shows that n must be 0. Hence we can not allow a `credit' of
 t_nom - t_now > t_ipi time units to accrue in the packet scheduling.


Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
 net/dccp/ccids/ccid3.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -362,7 +362,15 @@ static int ccid3_hc_tx_send_packet(struc
 	case TFRC_SSTATE_NO_FBACK:
 	case TFRC_SSTATE_FBACK:
 		delay = timeval_delta(&hctx->ccid3hctx_t_nom, &now);
-		ccid3_pr_debug("delay=%ld\n", (long)delay);
+		/*
+		 * Lagging behind for more than a full t_ipi: when this occurs,
+		 * a send credit accrues which causes packet storms, violating
+		 * even the average allowed sending rate. This case happens if
+		 * the application idles for some time, or if it emits packets
+		 * at a rate smaller than X/s. Avoid such accumulation.
+		 */
+		if (delay + (suseconds_t)hctx->ccid3hctx_t_ipi  <  0)
+			hctx->ccid3hctx_t_nom = now;
 		/*
 		 *	Scheduling of packet transmissions [RFC 3448, 4.6]
 		 *
@@ -371,7 +379,7 @@ static int ccid3_hc_tx_send_packet(struc
 		 * else
 		 *       // send the packet in (t_nom - t_now) milliseconds.
 		 */
-		if (delay - (suseconds_t)hctx->ccid3hctx_delta >= 0)
+		else if (delay - (suseconds_t)hctx->ccid3hctx_delta  >=  0)
 			return delay / 1000L;
 
 		ccid3_hc_tx_update_win_count(hctx, &now);

             reply	other threads:[~2007-03-21 18:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-21 18:44 Gerrit Renker [this message]
2007-03-26  2:33 ` [PATCH 2/25]: Avoid accumulation of large send credit Ian McDonald
2007-04-10 17:24 ` Eddie Kohler
2007-04-11 14:50 ` Gerrit Renker
2007-04-11 15:43 ` Eddie Kohler
2007-04-11 22:45 ` Ian McDonald
2007-04-12 11:40 ` Gerrit Renker
2007-04-12 12:55 ` Gerrit Renker
2007-04-12 14:39 ` Eddie Kohler
2007-04-13 18:27 ` Gerrit Renker
2007-04-13 20:37 ` Eddie Kohler
2007-04-13 20:58 ` David Miller
2007-04-13 21:45 ` Ian McDonald
2007-04-13 23:43 ` Eddie Kohler
2007-04-14  5:51 ` Eddie Kohler
2007-04-15 15:44 ` Gerrit Renker
2007-04-15 15:56 ` Gerrit Renker
2007-04-15 16:23 ` Gerrit Renker
2007-04-15 16:41 ` Gerrit Renker
2007-04-18 16:16 ` [dccp] " Colin Perkins
2007-04-18 16:48 ` Lars Eggert
2007-04-18 18:32 ` vlad.gm
2007-04-18 18:34 ` vlad.gm
2007-04-20  9:45 ` Gerrit Renker
2007-04-20 10:20 ` Ian McDonald
2007-04-20 10:56 ` Colin Perkins
2007-04-20 11:31 ` Gerrit Renker
2007-04-24 22:50 ` Colin Perkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703211844.12007@strip-the-willow \
    --to=gerrit@erg.abdn.ac.uk \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.