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);
next 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox