2005-08-09 21:14:34 -06:00
|
|
|
/*
|
|
|
|
|
* net/dccp/ccids/ccid3.c
|
|
|
|
|
*
|
2007-12-12 09:06:14 -07:00
|
|
|
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
|
2007-05-28 09:23:29 -06:00
|
|
|
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New Zealand.
|
|
|
|
|
* Copyright (c) 2005-7 Ian McDonald <ian.mcdonald@jandi.co.nz>
|
2005-08-09 21:14:34 -06:00
|
|
|
*
|
|
|
|
|
* An implementation of the DCCP protocol
|
|
|
|
|
*
|
|
|
|
|
* This code has been developed by the University of Waikato WAND
|
|
|
|
|
* research group. For further information please see http://www.wand.net.nz/
|
|
|
|
|
*
|
|
|
|
|
* This code also uses code from Lulea University, rereleased as GPL by its
|
|
|
|
|
* authors:
|
|
|
|
|
* Copyright (c) 2003 Nils-Erik Mattsson, Joacim Haggmark, Magnus Erixzon
|
|
|
|
|
*
|
|
|
|
|
* Changes to meet Linux coding standards, to make it meet latest ccid3 draft
|
|
|
|
|
* and to make it work as a loadable module in the DCCP stack written by
|
|
|
|
|
* Arnaldo Carvalho de Melo <acme@conectiva.com.br>.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2005 Arnaldo Carvalho de Melo <acme@conectiva.com.br>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
|
*/
|
|
|
|
|
#include "../dccp.h"
|
|
|
|
|
#include "ccid3.h"
|
|
|
|
|
|
2007-10-24 06:46:58 -06:00
|
|
|
#include <asm/unaligned.h>
|
|
|
|
|
|
2006-11-20 13:28:09 -07:00
|
|
|
#ifdef CONFIG_IP_DCCP_CCID3_DEBUG
|
|
|
|
|
static int ccid3_debug;
|
|
|
|
|
#define ccid3_pr_debug(format, a...) DCCP_PR_DEBUG(ccid3_debug, format, ##a)
|
2005-08-09 21:14:34 -06:00
|
|
|
#else
|
|
|
|
|
#define ccid3_pr_debug(format, a...)
|
|
|
|
|
#endif
|
|
|
|
|
|
2007-03-20 10:11:24 -06:00
|
|
|
/*
|
|
|
|
|
* Transmitter Half-Connection Routines
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
/* Oscillation Prevention/Reduction: recommended by rfc3448bis, on by default */
|
|
|
|
|
static int do_osc_prev = true;
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-03-20 12:12:10 -06:00
|
|
|
/*
|
2007-11-20 12:33:17 -07:00
|
|
|
* Compute the initial sending rate X_init in the manner of RFC 3390:
|
|
|
|
|
*
|
2008-09-03 23:30:19 -06:00
|
|
|
* X_init = min(4 * MPS, max(2 * MPS, 4380 bytes)) / RTT
|
2007-11-20 12:33:17 -07:00
|
|
|
*
|
2007-03-20 12:12:10 -06:00
|
|
|
* For consistency with other parts of the code, X_init is scaled by 2^6.
|
|
|
|
|
*/
|
|
|
|
|
static inline u64 rfc3390_initial_rate(struct sock *sk)
|
|
|
|
|
{
|
2008-09-03 23:30:19 -06:00
|
|
|
const u32 mps = dccp_sk(sk)->dccps_mss_cache,
|
|
|
|
|
w_init = clamp(4380U, 2 * mps, 4 * mps);
|
2007-03-20 12:12:10 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
return scaled_div(w_init << 6, ccid3_hc_tx_sk(sk)->rtt);
|
2007-03-20 12:12:10 -06:00
|
|
|
}
|
|
|
|
|
|
dccp ccid-3: Bug fix for the inter-packet scheduling algorithm
This fixes a subtle bug in the calculation of the inter-packet gap and shows
that t_delta, as it is currently used, is not needed. And hence replaced.
The algorithm from RFC 3448, 4.6 below continually computes a send time t_nom,
which is initialised with the current time t_now; t_gran = 1E6 / HZ specifies
the scheduling granularity, s the packet size, and X the sending rate:
t_distance = t_nom - t_now; // in microseconds
t_delta = min(t_ipi, t_gran) / 2; // `delta' parameter in microseconds
if (t_distance >= t_delta) {
reschedule after (t_distance / 1000) milliseconds;
} else {
t_ipi = s / X; // inter-packet interval in usec
t_nom += t_ipi; // compute the next send time
send packet now;
}
1) Description of the bug
-------------------------
Rescheduling requires a conversion into milliseconds, due to this call chain:
* ccid3_hc_tx_send_packet() returns a timeout in milliseconds,
* this value is converted by msecs_to_jiffies() in dccp_write_xmit(),
* and finally used as jiffy-expires-value for sk_reset_timer().
The highest jiffy resolution with HZ=1000 is 1 millisecond, so using a higher
granularity does not make much sense here.
As a consequence, values of t_distance < 1000 are truncated to 0. This issue
has so far been resolved by using instead
if (t_distance >= t_delta + 1000)
reschedule after (t_distance / 1000) milliseconds;
The bug is in artificially inflating t_delta to t_delta' = t_delta + 1000. This
is unnecessarily large, a more adequate value is t_delta' = max(t_delta, 1000).
2) Consequences of using the corrected t_delta'
-----------------------------------------------
Since t_delta <= t_gran/2 = 10^6/(2*HZ), we have t_delta <= 1000 as long as
HZ >= 500. This means that t_delta' = max(1000, t_delta) is constant at 1000.
On the other hand, when using a coarse HZ value of HZ < 500, we have three
sub-cases that can all be reduced to using another constant of t_gran/2.
(a) The first case arises when t_ipi > t_gran. Here t_delta' is the constant
t_delta' = max(1000, t_gran/2) = t_gran/2.
(b) If t_ipi <= 2000 < t_gran = 10^6/HZ usec, then t_delta = t_ipi/2 <= 1000,
so that t_delta' = max(1000, t_delta) = 1000 < t_gran/2.
(c) If 2000 < t_ipi <= t_gran, we have t_delta' = max(t_delta, 1000) = t_ipi/2.
In the second and third cases we have delay values less than t_gran/2, which is
in the order of less than or equal to half a jiffy.
How these are treated depends on how fractions of a jiffy are handled: they
are either always rounded down to 0, or always rounded up to 1 jiffy (assuming
non-zero values). In both cases the error is on average in the order of 50%.
Thus we are not increasing the error when in the second/third case we replace
a value less than t_gran/2 with 0, by setting t_delta' to the constant t_gran/2.
3) Summary
----------
Fixing (1) and considering (2), the patch replaces t_delta with a constant,
whose value depends on CONFIG_HZ, changing the above algorithm to:
if (t_distance >= t_delta')
reschedule after (t_distance / 1000) milliseconds;
where t_delta' = 10^6/(2*HZ) if HZ < 500, and t_delta' = 1000 otherwise.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
/**
|
dccp ccid-3: Simplify computing and range-checking of t_ipi
This patch simplifies the computation of t_ipi, avoiding expensive computations
to enforce the minimum sending rate.
Both RFC 3448 and rfc3448bis (revision #06), as well as RFC 4342 sec 5., require
at various stages that at least one packet must be sent per t_mbi = 64 seconds.
This requires frequent divisions of the type X_min = s/t_mbi, which are later
converted back into an inter-packet-interval t_ipi_max = s/X_min = t_mbi.
The patch removes the expensive indirection; in the unlikely case of having
a sending rate less than one packet per 64 seconds, it also re-adjusts X.
The following cases document conformance with RFC 3448 / rfc3448bis-06:
1) Time until receiving the first feedback packet:
* if the sender has no initial RTT sample then X = s/1 Bps > s/t_mbi;
* if the sender has an initial RTT sample or when the first feedback
packet is received, X = W_init/R > s/t_mbi.
2) Slow-start (p == 0 and feedback packets come in):
* RFC 3448 (current code) enforces a minimum of s/R > s/t_mbi;
* rfc3448bis (future code) enforces an even higher minimum of W_init/R.
3) Congestion avoidance with no absence of feedback (p > 0):
* when X_calc or X_recv/2 are too low, the minimum of X_min = s/t_mbi
is enforced in update_x() when calling update_send_interval();
* update_send_interval() is, as before, only called when X changes
(i.e. either when increasing or decreasing, not when in equilibrium).
4) Reduction of X without prior feedback or during slow-start (p==0):
* both RFC 3448 and rfc3448bis here halve X directly;
* the associated constraint X >= s/t_mbi is nforced here by send_interval().
5) Reduction of X when p > 0:
* X is modified indirectly via X_recv (RFC 3448) or X_recv_set (rfc3448bis);
* in both cases, control goes back to section 4.3 (in both documents);
* since p > 0, both documents use X = max(min(...), s/t_mbi), which is
enforced in this patch by calling send_interval() from update_x().
I think that this analysis is exhaustive. Should I have forgotten a case,
the worst-case consideration arises when X sinks below s/t_mbi, and is then
increased back up to this minimum value. Even under this assumption, the
behaviour is correct, since all lower limits of X in RFC 3448 / rfc3448bis
are either equal to or greater than s/t_mbi.
Note on the condition X >= s/t_mbi <==> t_ipi = s/X <= t_mbi: since X is
scaled by 64, and all time units are in microseconds, the coded condition is:
t_ipi = s * 64 * 10^6 usec / X <= 64 * 10^6 usec
This simplifies to s / X <= 1 second <==> X * 1 second >= s > 0.
(A zero `s' is not allowed by the CCID-3 code).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
* ccid3_update_send_interval - Calculate new t_ipi = s / X
|
|
|
|
|
* This respects the granularity of X (64 * bytes/second) and enforces the
|
|
|
|
|
* scaled minimum of s * 64 / t_mbi = `s' bytes/second as per RFC 3448/4342.
|
2006-11-27 15:31:33 -07:00
|
|
|
*/
|
2008-01-06 00:13:58 -07:00
|
|
|
static void ccid3_update_send_interval(struct ccid3_hc_tx_sock *hctx)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
dccp ccid-3: Simplify computing and range-checking of t_ipi
This patch simplifies the computation of t_ipi, avoiding expensive computations
to enforce the minimum sending rate.
Both RFC 3448 and rfc3448bis (revision #06), as well as RFC 4342 sec 5., require
at various stages that at least one packet must be sent per t_mbi = 64 seconds.
This requires frequent divisions of the type X_min = s/t_mbi, which are later
converted back into an inter-packet-interval t_ipi_max = s/X_min = t_mbi.
The patch removes the expensive indirection; in the unlikely case of having
a sending rate less than one packet per 64 seconds, it also re-adjusts X.
The following cases document conformance with RFC 3448 / rfc3448bis-06:
1) Time until receiving the first feedback packet:
* if the sender has no initial RTT sample then X = s/1 Bps > s/t_mbi;
* if the sender has an initial RTT sample or when the first feedback
packet is received, X = W_init/R > s/t_mbi.
2) Slow-start (p == 0 and feedback packets come in):
* RFC 3448 (current code) enforces a minimum of s/R > s/t_mbi;
* rfc3448bis (future code) enforces an even higher minimum of W_init/R.
3) Congestion avoidance with no absence of feedback (p > 0):
* when X_calc or X_recv/2 are too low, the minimum of X_min = s/t_mbi
is enforced in update_x() when calling update_send_interval();
* update_send_interval() is, as before, only called when X changes
(i.e. either when increasing or decreasing, not when in equilibrium).
4) Reduction of X without prior feedback or during slow-start (p==0):
* both RFC 3448 and rfc3448bis here halve X directly;
* the associated constraint X >= s/t_mbi is nforced here by send_interval().
5) Reduction of X when p > 0:
* X is modified indirectly via X_recv (RFC 3448) or X_recv_set (rfc3448bis);
* in both cases, control goes back to section 4.3 (in both documents);
* since p > 0, both documents use X = max(min(...), s/t_mbi), which is
enforced in this patch by calling send_interval() from update_x().
I think that this analysis is exhaustive. Should I have forgotten a case,
the worst-case consideration arises when X sinks below s/t_mbi, and is then
increased back up to this minimum value. Even under this assumption, the
behaviour is correct, since all lower limits of X in RFC 3448 / rfc3448bis
are either equal to or greater than s/t_mbi.
Note on the condition X >= s/t_mbi <==> t_ipi = s/X <= t_mbi: since X is
scaled by 64, and all time units are in microseconds, the coded condition is:
t_ipi = s * 64 * 10^6 usec / X <= 64 * 10^6 usec
This simplifies to s / X <= 1 second <==> X * 1 second >= s > 0.
(A zero `s' is not allowed by the CCID-3 code).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
if (unlikely(hctx->x <= hctx->s))
|
|
|
|
|
hctx->x = hctx->s;
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->t_ipi = scaled_div32(((u64)hctx->s) << 6, hctx->x);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
2007-09-25 23:39:16 -06:00
|
|
|
|
2007-11-20 13:01:59 -07:00
|
|
|
static u32 ccid3_hc_tx_idle_rtt(struct ccid3_hc_tx_sock *hctx, ktime_t now)
|
|
|
|
|
{
|
2008-09-03 23:30:19 -06:00
|
|
|
u32 delta = ktime_us_delta(now, hctx->t_last_win_count);
|
2007-11-20 13:01:59 -07:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
return delta / hctx->rtt;
|
2007-11-20 13:01:59 -07:00
|
|
|
}
|
|
|
|
|
|
2007-09-25 23:39:16 -06:00
|
|
|
/**
|
|
|
|
|
* ccid3_hc_tx_update_x - Update allowed sending rate X
|
|
|
|
|
* @stamp: most recent time if available - can be left NULL.
|
|
|
|
|
* This function tracks draft rfc3448bis, check there for latest details.
|
2006-12-03 09:50:56 -07:00
|
|
|
*
|
2006-12-09 19:02:12 -07:00
|
|
|
* Note: X and X_recv are both stored in units of 64 * bytes/second, to support
|
|
|
|
|
* fine-grained resolution of sending rates. This requires scaling by 2^6
|
|
|
|
|
* throughout the code. Only X_calc is unscaled (in bytes/second).
|
|
|
|
|
*
|
|
|
|
|
*/
|
2007-09-25 23:39:16 -06:00
|
|
|
static void ccid3_hc_tx_update_x(struct sock *sk, ktime_t *stamp)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2008-09-03 23:30:19 -06:00
|
|
|
u64 min_rate = 2 * hctx->x_recv;
|
|
|
|
|
const u64 old_x = hctx->x;
|
2007-12-17 07:57:43 -07:00
|
|
|
ktime_t now = stamp ? *stamp : ktime_get_real();
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-03-20 12:19:07 -06:00
|
|
|
/*
|
|
|
|
|
* Handle IDLE periods: do not reduce below RFC3390 initial sending rate
|
2007-11-20 13:01:59 -07:00
|
|
|
* when idling [RFC 4342, 5.1]. Definition of idling is from rfc3448bis:
|
|
|
|
|
* a sender is idle if it has not sent anything over a 2-RTT-period.
|
2007-03-20 12:19:07 -06:00
|
|
|
* For consistency with X and X_recv, min_rate is also scaled by 2^6.
|
|
|
|
|
*/
|
2007-11-20 13:01:59 -07:00
|
|
|
if (ccid3_hc_tx_idle_rtt(hctx, now) >= 2) {
|
2007-03-20 12:19:07 -06:00
|
|
|
min_rate = rfc3390_initial_rate(sk);
|
2008-09-03 23:30:19 -06:00
|
|
|
min_rate = max(min_rate, 2 * hctx->x_recv);
|
2007-03-20 12:19:07 -06:00
|
|
|
}
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hctx->p > 0) {
|
2006-12-09 19:02:12 -07:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x = min(((u64)hctx->x_calc) << 6, min_rate);
|
2006-11-28 14:51:42 -07:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
} else if (ktime_us_delta(now, hctx->t_ld) - (s64)hctx->rtt >= 0) {
|
2007-08-19 18:14:27 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x = min(2 * hctx->x, min_rate);
|
|
|
|
|
hctx->x = max(hctx->x,
|
|
|
|
|
scaled_div(((u64)hctx->s) << 6, hctx->rtt));
|
|
|
|
|
hctx->t_ld = now;
|
2006-12-09 19:00:14 -07:00
|
|
|
}
|
2005-08-27 15:18:18 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hctx->x != old_x) {
|
2007-03-20 12:04:30 -06:00
|
|
|
ccid3_pr_debug("X_prev=%u, X_now=%u, X_calc=%u, "
|
|
|
|
|
"X_recv=%u\n", (unsigned)(old_x >> 6),
|
2008-09-03 23:30:19 -06:00
|
|
|
(unsigned)(hctx->x >> 6), hctx->x_calc,
|
|
|
|
|
(unsigned)(hctx->x_recv >> 6));
|
2007-03-20 11:49:20 -06:00
|
|
|
|
2007-03-20 11:56:11 -06:00
|
|
|
ccid3_update_send_interval(hctx);
|
2007-03-20 11:49:20 -06:00
|
|
|
}
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2006-11-28 14:22:33 -07:00
|
|
|
/*
|
dccp ccid-3: Measuring the packet size s with regard to rfc3448bis-06
rfc3448bis allows three different ways of tracking the packet size `s':
1. using the MSS/MPS (at initialisation, 4.2, and in 4.1 (1));
2. using the average of `s' (in 4.1);
3. using the maximum of `s' (in 4.2).
Instead of hard-coding a single interpretation of rfc3448bis, this implements
a choice of all three alternatives and suggests the first as default, since it
is the option which is most consistent with other parts of the specification.
The patch further deprecates the update of t_ipi whenever `s' changes. The
gains of doing this are only small since a change of s takes effect at the
next instant X is updated:
* when the next feedback comes in (within one RTT or less);
* when the nofeedback timer expires (within at most 4 RTTs).
Further, there are complications caused by updating t_ipi whenever s changes:
* if t_ipi had previously been updated to effect oscillation prevention (4.5),
then it is impossible to make the same adjustment to t_ipi again, thus
counter-acting the algorithm;
* s may be updated any time and a modification of t_ipi depends on the current
state (e.g. no oscillation prevention is done in the absence of feedback);
* in rev-06 of rfc3448bis, there are more possible cases, depending on whether
the sender is in slow-start (t_ipi <= R/W_init), or in congestion-avoidance,
limited by X_recv or the throughput equation (t_ipi <= t_mbi).
Thus there are side effects of always updating t_ipi as s changes. These may not
be desirable. The only case I can think of where such an update makes sense is
to recompute X_calc when p > 0 and when s changes (not done by this patch).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
* ccid3_hc_tx_measure_packet_size - Measuring the packet size `s' (sec 4.1)
|
|
|
|
|
* @new_len: DCCP payload size in bytes (not used by all methods)
|
2006-11-28 14:22:33 -07:00
|
|
|
*/
|
dccp ccid-3: Measuring the packet size s with regard to rfc3448bis-06
rfc3448bis allows three different ways of tracking the packet size `s':
1. using the MSS/MPS (at initialisation, 4.2, and in 4.1 (1));
2. using the average of `s' (in 4.1);
3. using the maximum of `s' (in 4.2).
Instead of hard-coding a single interpretation of rfc3448bis, this implements
a choice of all three alternatives and suggests the first as default, since it
is the option which is most consistent with other parts of the specification.
The patch further deprecates the update of t_ipi whenever `s' changes. The
gains of doing this are only small since a change of s takes effect at the
next instant X is updated:
* when the next feedback comes in (within one RTT or less);
* when the nofeedback timer expires (within at most 4 RTTs).
Further, there are complications caused by updating t_ipi whenever s changes:
* if t_ipi had previously been updated to effect oscillation prevention (4.5),
then it is impossible to make the same adjustment to t_ipi again, thus
counter-acting the algorithm;
* s may be updated any time and a modification of t_ipi depends on the current
state (e.g. no oscillation prevention is done in the absence of feedback);
* in rev-06 of rfc3448bis, there are more possible cases, depending on whether
the sender is in slow-start (t_ipi <= R/W_init), or in congestion-avoidance,
limited by X_recv or the throughput equation (t_ipi <= t_mbi).
Thus there are side effects of always updating t_ipi as s changes. These may not
be desirable. The only case I can think of where such an update makes sense is
to recompute X_calc when p > 0 and when s changes (not done by this patch).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
static u32 ccid3_hc_tx_measure_packet_size(struct sock *sk, const u16 new_len)
|
2006-11-28 14:22:33 -07:00
|
|
|
{
|
dccp ccid-3: Measuring the packet size s with regard to rfc3448bis-06
rfc3448bis allows three different ways of tracking the packet size `s':
1. using the MSS/MPS (at initialisation, 4.2, and in 4.1 (1));
2. using the average of `s' (in 4.1);
3. using the maximum of `s' (in 4.2).
Instead of hard-coding a single interpretation of rfc3448bis, this implements
a choice of all three alternatives and suggests the first as default, since it
is the option which is most consistent with other parts of the specification.
The patch further deprecates the update of t_ipi whenever `s' changes. The
gains of doing this are only small since a change of s takes effect at the
next instant X is updated:
* when the next feedback comes in (within one RTT or less);
* when the nofeedback timer expires (within at most 4 RTTs).
Further, there are complications caused by updating t_ipi whenever s changes:
* if t_ipi had previously been updated to effect oscillation prevention (4.5),
then it is impossible to make the same adjustment to t_ipi again, thus
counter-acting the algorithm;
* s may be updated any time and a modification of t_ipi depends on the current
state (e.g. no oscillation prevention is done in the absence of feedback);
* in rev-06 of rfc3448bis, there are more possible cases, depending on whether
the sender is in slow-start (t_ipi <= R/W_init), or in congestion-avoidance,
limited by X_recv or the throughput equation (t_ipi <= t_mbi).
Thus there are side effects of always updating t_ipi as s changes. These may not
be desirable. The only case I can think of where such an update makes sense is
to recompute X_calc when p > 0 and when s changes (not done by this patch).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
#if defined(CONFIG_IP_DCCP_CCID3_MEASURE_S_AS_AVG)
|
|
|
|
|
return tfrc_ewma(ccid3_hc_tx_sk(sk)->s, new_len, 9);
|
|
|
|
|
#elif defined(CONFIG_IP_DCCP_CCID3_MEASURE_S_AS_MAX)
|
|
|
|
|
return max(ccid3_hc_tx_sk(sk)->s, new_len);
|
|
|
|
|
#else /* CONFIG_IP_DCCP_CCID3_MEASURE_S_AS_MPS */
|
|
|
|
|
return dccp_sk(sk)->dccps_mss_cache;
|
|
|
|
|
#endif
|
2006-11-28 14:22:33 -07:00
|
|
|
}
|
|
|
|
|
|
2006-12-09 19:07:37 -07:00
|
|
|
/*
|
2006-12-10 11:01:18 -07:00
|
|
|
* Update Window Counter using the algorithm from [RFC 4342, 8.1].
|
2008-05-27 07:33:54 -06:00
|
|
|
* As elsewhere, RTT > 0 is assumed by using dccp_sample_rtt().
|
2006-12-09 19:07:37 -07:00
|
|
|
*/
|
|
|
|
|
static inline void ccid3_hc_tx_update_win_count(struct ccid3_hc_tx_sock *hctx,
|
2007-06-16 10:34:02 -06:00
|
|
|
ktime_t now)
|
2006-12-09 19:07:37 -07:00
|
|
|
{
|
2008-09-03 23:30:19 -06:00
|
|
|
u32 delta = ktime_us_delta(now, hctx->t_last_win_count),
|
|
|
|
|
quarter_rtts = (4 * delta) / hctx->rtt;
|
2006-12-09 19:07:37 -07:00
|
|
|
|
|
|
|
|
if (quarter_rtts > 0) {
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->t_last_win_count = now;
|
|
|
|
|
hctx->last_win_count += min(quarter_rtts, 5U);
|
|
|
|
|
hctx->last_win_count &= 0xF; /* mod 16 */
|
2006-12-09 19:07:37 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-09 21:14:34 -06:00
|
|
|
static void ccid3_hc_tx_no_feedback_timer(unsigned long data)
|
|
|
|
|
{
|
|
|
|
|
struct sock *sk = (struct sock *)data;
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2006-11-28 13:34:34 -07:00
|
|
|
unsigned long t_nfb = USEC_PER_SEC / 5;
|
2005-08-09 21:14:34 -06:00
|
|
|
|
|
|
|
|
bh_lock_sock(sk);
|
|
|
|
|
if (sock_owned_by_user(sk)) {
|
|
|
|
|
/* Try again later. */
|
|
|
|
|
/* XXX: set some sensible MIB */
|
2006-11-27 15:29:27 -07:00
|
|
|
goto restart_timer;
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
ccid3_pr_debug("%s(%p) entry with%s feedback\n", dccp_role(sk), sk,
|
|
|
|
|
hctx->feedback ? "" : "out");
|
2006-12-09 19:14:12 -07:00
|
|
|
|
dccp ccid-3: Remove dead states
This patch is thanks to an investigation by Leandro Sales de Melo and his
colleagues. They worked out two state diagrams which highlight the fact that
the xxx_TERM states in CCID-3/4 are in fact not necessary.
And this can be confirmed by in turn looking at the code: the xxx_TERM states
are only ever set in ccid3_hc_{rx,tx}_exit(). These two functions are part
of the following call chain:
* ccid_hc_{tx,rx}_exit() are called from ccid_delete() only;
* ccid_delete() invokes ccid_hc_{tx,rx}_exit() in the way of a destructor:
after calling ccid_hc_{tx,rx}_exit(), the CCID is released from memory;
* ccid_delete() is in turn called only by ccid_hc_{tx,rx}_delete();
* ccid_hc_{tx,rx}_delete() is called only if
- feature negotiation failed (dccp_feat_activate_values()),
- when changing the RX/TX CCID (to eject the current CCID),
- when destroying the socket (in dccp_destroy_sock()).
In other words, when CCID-3 sets the state to xxx_TERM, it is at a time where
no more processing should be going on, hence it is not necessary to introduce
a dedicated exit state - this is implicit when unloading the CCID.
The patch removes this state, one switch-statement collapses as a result.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
/* Ignore and do not restart after leaving the established state */
|
|
|
|
|
if ((1 << sk->sk_state) & ~(DCCPF_OPEN | DCCPF_PARTOPEN))
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
/* Reset feedback state to "no feedback received" */
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->feedback = false;
|
2007-12-17 07:57:43 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Determine new allowed sending rate X as per draft rfc3448bis-00, 4.4
|
2008-09-03 23:30:19 -06:00
|
|
|
* RTO is 0 if and only if no feedback has been received yet.
|
2007-12-17 07:57:43 -07:00
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hctx->t_rto == 0 || hctx->p == 0) {
|
2007-12-17 07:57:43 -07:00
|
|
|
|
|
|
|
|
/* halve send rate directly */
|
dccp ccid-3: Simplify computing and range-checking of t_ipi
This patch simplifies the computation of t_ipi, avoiding expensive computations
to enforce the minimum sending rate.
Both RFC 3448 and rfc3448bis (revision #06), as well as RFC 4342 sec 5., require
at various stages that at least one packet must be sent per t_mbi = 64 seconds.
This requires frequent divisions of the type X_min = s/t_mbi, which are later
converted back into an inter-packet-interval t_ipi_max = s/X_min = t_mbi.
The patch removes the expensive indirection; in the unlikely case of having
a sending rate less than one packet per 64 seconds, it also re-adjusts X.
The following cases document conformance with RFC 3448 / rfc3448bis-06:
1) Time until receiving the first feedback packet:
* if the sender has no initial RTT sample then X = s/1 Bps > s/t_mbi;
* if the sender has an initial RTT sample or when the first feedback
packet is received, X = W_init/R > s/t_mbi.
2) Slow-start (p == 0 and feedback packets come in):
* RFC 3448 (current code) enforces a minimum of s/R > s/t_mbi;
* rfc3448bis (future code) enforces an even higher minimum of W_init/R.
3) Congestion avoidance with no absence of feedback (p > 0):
* when X_calc or X_recv/2 are too low, the minimum of X_min = s/t_mbi
is enforced in update_x() when calling update_send_interval();
* update_send_interval() is, as before, only called when X changes
(i.e. either when increasing or decreasing, not when in equilibrium).
4) Reduction of X without prior feedback or during slow-start (p==0):
* both RFC 3448 and rfc3448bis here halve X directly;
* the associated constraint X >= s/t_mbi is nforced here by send_interval().
5) Reduction of X when p > 0:
* X is modified indirectly via X_recv (RFC 3448) or X_recv_set (rfc3448bis);
* in both cases, control goes back to section 4.3 (in both documents);
* since p > 0, both documents use X = max(min(...), s/t_mbi), which is
enforced in this patch by calling send_interval() from update_x().
I think that this analysis is exhaustive. Should I have forgotten a case,
the worst-case consideration arises when X sinks below s/t_mbi, and is then
increased back up to this minimum value. Even under this assumption, the
behaviour is correct, since all lower limits of X in RFC 3448 / rfc3448bis
are either equal to or greater than s/t_mbi.
Note on the condition X >= s/t_mbi <==> t_ipi = s/X <= t_mbi: since X is
scaled by 64, and all time units are in microseconds, the coded condition is:
t_ipi = s * 64 * 10^6 usec / X <= 64 * 10^6 usec
This simplifies to s / X <= 1 second <==> X * 1 second >= s > 0.
(A zero `s' is not allowed by the CCID-3 code).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x /= 2;
|
2007-03-20 11:56:11 -06:00
|
|
|
ccid3_update_send_interval(hctx);
|
dccp ccid-3: Simplify computing and range-checking of t_ipi
This patch simplifies the computation of t_ipi, avoiding expensive computations
to enforce the minimum sending rate.
Both RFC 3448 and rfc3448bis (revision #06), as well as RFC 4342 sec 5., require
at various stages that at least one packet must be sent per t_mbi = 64 seconds.
This requires frequent divisions of the type X_min = s/t_mbi, which are later
converted back into an inter-packet-interval t_ipi_max = s/X_min = t_mbi.
The patch removes the expensive indirection; in the unlikely case of having
a sending rate less than one packet per 64 seconds, it also re-adjusts X.
The following cases document conformance with RFC 3448 / rfc3448bis-06:
1) Time until receiving the first feedback packet:
* if the sender has no initial RTT sample then X = s/1 Bps > s/t_mbi;
* if the sender has an initial RTT sample or when the first feedback
packet is received, X = W_init/R > s/t_mbi.
2) Slow-start (p == 0 and feedback packets come in):
* RFC 3448 (current code) enforces a minimum of s/R > s/t_mbi;
* rfc3448bis (future code) enforces an even higher minimum of W_init/R.
3) Congestion avoidance with no absence of feedback (p > 0):
* when X_calc or X_recv/2 are too low, the minimum of X_min = s/t_mbi
is enforced in update_x() when calling update_send_interval();
* update_send_interval() is, as before, only called when X changes
(i.e. either when increasing or decreasing, not when in equilibrium).
4) Reduction of X without prior feedback or during slow-start (p==0):
* both RFC 3448 and rfc3448bis here halve X directly;
* the associated constraint X >= s/t_mbi is nforced here by send_interval().
5) Reduction of X when p > 0:
* X is modified indirectly via X_recv (RFC 3448) or X_recv_set (rfc3448bis);
* in both cases, control goes back to section 4.3 (in both documents);
* since p > 0, both documents use X = max(min(...), s/t_mbi), which is
enforced in this patch by calling send_interval() from update_x().
I think that this analysis is exhaustive. Should I have forgotten a case,
the worst-case consideration arises when X sinks below s/t_mbi, and is then
increased back up to this minimum value. Even under this assumption, the
behaviour is correct, since all lower limits of X in RFC 3448 / rfc3448bis
are either equal to or greater than s/t_mbi.
Note on the condition X >= s/t_mbi <==> t_ipi = s/X <= t_mbi: since X is
scaled by 64, and all time units are in microseconds, the coded condition is:
t_ipi = s * 64 * 10^6 usec / X <= 64 * 10^6 usec
This simplifies to s / X <= 1 second <==> X * 1 second >= s > 0.
(A zero `s' is not allowed by the CCID-3 code).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
|
2007-12-17 07:57:43 -07:00
|
|
|
} else {
|
2005-08-27 00:51:58 -06:00
|
|
|
/*
|
2007-12-17 07:57:43 -07:00
|
|
|
* Modify the cached value of X_recv
|
2007-03-20 12:19:07 -06:00
|
|
|
*
|
2007-12-17 07:57:43 -07:00
|
|
|
* If (X_calc > 2 * X_recv)
|
2007-03-20 12:19:07 -06:00
|
|
|
* X_recv = max(X_recv / 2, s / (2 * t_mbi));
|
|
|
|
|
* Else
|
|
|
|
|
* X_recv = X_calc / 4;
|
|
|
|
|
*
|
|
|
|
|
* Note that X_recv is scaled by 2^6 while X_calc is not
|
2005-08-27 00:51:58 -06:00
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
BUG_ON(hctx->p && !hctx->x_calc);
|
2007-03-20 12:19:07 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hctx->x_calc > (hctx->x_recv >> 5))
|
dccp ccid-3: Simplify computing and range-checking of t_ipi
This patch simplifies the computation of t_ipi, avoiding expensive computations
to enforce the minimum sending rate.
Both RFC 3448 and rfc3448bis (revision #06), as well as RFC 4342 sec 5., require
at various stages that at least one packet must be sent per t_mbi = 64 seconds.
This requires frequent divisions of the type X_min = s/t_mbi, which are later
converted back into an inter-packet-interval t_ipi_max = s/X_min = t_mbi.
The patch removes the expensive indirection; in the unlikely case of having
a sending rate less than one packet per 64 seconds, it also re-adjusts X.
The following cases document conformance with RFC 3448 / rfc3448bis-06:
1) Time until receiving the first feedback packet:
* if the sender has no initial RTT sample then X = s/1 Bps > s/t_mbi;
* if the sender has an initial RTT sample or when the first feedback
packet is received, X = W_init/R > s/t_mbi.
2) Slow-start (p == 0 and feedback packets come in):
* RFC 3448 (current code) enforces a minimum of s/R > s/t_mbi;
* rfc3448bis (future code) enforces an even higher minimum of W_init/R.
3) Congestion avoidance with no absence of feedback (p > 0):
* when X_calc or X_recv/2 are too low, the minimum of X_min = s/t_mbi
is enforced in update_x() when calling update_send_interval();
* update_send_interval() is, as before, only called when X changes
(i.e. either when increasing or decreasing, not when in equilibrium).
4) Reduction of X without prior feedback or during slow-start (p==0):
* both RFC 3448 and rfc3448bis here halve X directly;
* the associated constraint X >= s/t_mbi is nforced here by send_interval().
5) Reduction of X when p > 0:
* X is modified indirectly via X_recv (RFC 3448) or X_recv_set (rfc3448bis);
* in both cases, control goes back to section 4.3 (in both documents);
* since p > 0, both documents use X = max(min(...), s/t_mbi), which is
enforced in this patch by calling send_interval() from update_x().
I think that this analysis is exhaustive. Should I have forgotten a case,
the worst-case consideration arises when X sinks below s/t_mbi, and is then
increased back up to this minimum value. Even under this assumption, the
behaviour is correct, since all lower limits of X in RFC 3448 / rfc3448bis
are either equal to or greater than s/t_mbi.
Note on the condition X >= s/t_mbi <==> t_ipi = s/X <= t_mbi: since X is
scaled by 64, and all time units are in microseconds, the coded condition is:
t_ipi = s * 64 * 10^6 usec / X <= 64 * 10^6 usec
This simplifies to s / X <= 1 second <==> X * 1 second >= s > 0.
(A zero `s' is not allowed by the CCID-3 code).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x_recv /= 2;
|
2007-12-17 07:57:43 -07:00
|
|
|
else {
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x_recv = hctx->x_calc;
|
|
|
|
|
hctx->x_recv <<= 4;
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
2007-09-25 23:39:16 -06:00
|
|
|
ccid3_hc_tx_update_x(sk, NULL);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
2007-12-17 07:57:43 -07:00
|
|
|
ccid3_pr_debug("Reduced X to %llu/64 bytes/sec\n",
|
2008-09-03 23:30:19 -06:00
|
|
|
(unsigned long long)hctx->x);
|
2007-12-17 07:57:43 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set new timeout for the nofeedback timer.
|
|
|
|
|
* See comments in packet_recv() regarding the value of t_RTO.
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
if (unlikely(hctx->t_rto == 0)) /* no feedback received yet */
|
2007-12-17 07:57:43 -07:00
|
|
|
t_nfb = TFRC_INITIAL_TIMEOUT;
|
|
|
|
|
else
|
2008-09-03 23:30:19 -06:00
|
|
|
t_nfb = max(hctx->t_rto, 2 * hctx->t_ipi);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2006-11-27 15:29:27 -07:00
|
|
|
restart_timer:
|
2008-09-03 23:30:19 -06:00
|
|
|
sk_reset_timer(sk, &hctx->no_feedback_timer,
|
2007-02-09 07:24:38 -07:00
|
|
|
jiffies + usecs_to_jiffies(t_nfb));
|
2005-08-09 21:14:34 -06:00
|
|
|
out:
|
|
|
|
|
bh_unlock_sock(sk);
|
|
|
|
|
sock_put(sk);
|
|
|
|
|
}
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
/**
|
|
|
|
|
* ccid3_hc_tx_send_packet - Delay-based dequeueing of TX packets
|
|
|
|
|
* @skb: next packet candidate to send on @sk
|
|
|
|
|
* This function uses the convention of ccid_packet_dequeue_eval() and
|
|
|
|
|
* returns a millisecond-delay value between 0 and t_mbi = 64000 msec.
|
2006-11-27 07:26:03 -07:00
|
|
|
*/
|
2006-11-28 14:55:06 -07:00
|
|
|
static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2007-06-16 10:34:02 -06:00
|
|
|
ktime_t now = ktime_get_real();
|
|
|
|
|
s64 delay;
|
2005-08-09 21:14:34 -06:00
|
|
|
|
|
|
|
|
/*
|
2006-11-27 07:26:57 -07:00
|
|
|
* This function is called only for Data and DataAck packets. Sending
|
|
|
|
|
* zero-sized Data(Ack)s is theoretically possible, but for congestion
|
|
|
|
|
* control this case is pathological - ignore it.
|
2005-08-09 21:14:34 -06:00
|
|
|
*/
|
2006-11-28 14:55:06 -07:00
|
|
|
if (unlikely(skb->len == 0))
|
2006-11-27 07:26:57 -07:00
|
|
|
return -EBADMSG;
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hctx->s == 0) {
|
2008-09-03 23:30:19 -06:00
|
|
|
sk_reset_timer(sk, &hctx->no_feedback_timer, (jiffies +
|
2007-02-09 07:24:38 -07:00
|
|
|
usecs_to_jiffies(TFRC_INITIAL_TIMEOUT)));
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->last_win_count = 0;
|
|
|
|
|
hctx->t_last_win_count = now;
|
2006-11-27 07:13:38 -07:00
|
|
|
|
|
|
|
|
/* Set t_0 for initial packet */
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->t_nom = now;
|
2007-03-20 12:31:56 -06:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Use initial RTT sample when available: recommended by erratum
|
|
|
|
|
* to RFC 4342. This implements the initialisation procedure of
|
|
|
|
|
* draft rfc3448bis, section 4.2. Remember, X is scaled by 2^6.
|
|
|
|
|
*/
|
|
|
|
|
if (dp->dccps_syn_rtt) {
|
|
|
|
|
ccid3_pr_debug("SYN RTT = %uus\n", dp->dccps_syn_rtt);
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->rtt = dp->dccps_syn_rtt;
|
|
|
|
|
hctx->x = rfc3390_initial_rate(sk);
|
|
|
|
|
hctx->t_ld = now;
|
2007-03-20 12:31:56 -06:00
|
|
|
} else {
|
2008-06-11 04:19:09 -06:00
|
|
|
/*
|
|
|
|
|
* Sender does not have RTT sample:
|
|
|
|
|
* - set fallback RTT (RFC 4340, 3.4) since a RTT value
|
|
|
|
|
* is needed in several parts (e.g. window counter);
|
|
|
|
|
* - set sending rate X_pps = 1pps as per RFC 3448, 4.2.
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->rtt = DCCP_FALLBACK_RTT;
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x = dp->dccps_mss_cache;
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x <<= 6;
|
2007-03-20 12:31:56 -06:00
|
|
|
}
|
dccp ccid-3: Measuring the packet size s with regard to rfc3448bis-06
rfc3448bis allows three different ways of tracking the packet size `s':
1. using the MSS/MPS (at initialisation, 4.2, and in 4.1 (1));
2. using the average of `s' (in 4.1);
3. using the maximum of `s' (in 4.2).
Instead of hard-coding a single interpretation of rfc3448bis, this implements
a choice of all three alternatives and suggests the first as default, since it
is the option which is most consistent with other parts of the specification.
The patch further deprecates the update of t_ipi whenever `s' changes. The
gains of doing this are only small since a change of s takes effect at the
next instant X is updated:
* when the next feedback comes in (within one RTT or less);
* when the nofeedback timer expires (within at most 4 RTTs).
Further, there are complications caused by updating t_ipi whenever s changes:
* if t_ipi had previously been updated to effect oscillation prevention (4.5),
then it is impossible to make the same adjustment to t_ipi again, thus
counter-acting the algorithm;
* s may be updated any time and a modification of t_ipi depends on the current
state (e.g. no oscillation prevention is done in the absence of feedback);
* in rev-06 of rfc3448bis, there are more possible cases, depending on whether
the sender is in slow-start (t_ipi <= R/W_init), or in congestion-avoidance,
limited by X_recv or the throughput equation (t_ipi <= t_mbi).
Thus there are side effects of always updating t_ipi as s changes. These may not
be desirable. The only case I can think of where such an update makes sense is
to recompute X_calc when p > 0 and when s changes (not done by this patch).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
|
|
|
|
|
/* Compute t_ipi = s / X */
|
|
|
|
|
hctx->s = ccid3_hc_tx_measure_packet_size(sk, skb->len);
|
2007-03-20 12:31:56 -06:00
|
|
|
ccid3_update_send_interval(hctx);
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
/* Seed value for Oscillation Prevention (sec. 4.5) */
|
|
|
|
|
hctx->r_sqmean = tfrc_scaled_sqrt(hctx->rtt);
|
|
|
|
|
|
dccp ccid-3: Remove dead states
This patch is thanks to an investigation by Leandro Sales de Melo and his
colleagues. They worked out two state diagrams which highlight the fact that
the xxx_TERM states in CCID-3/4 are in fact not necessary.
And this can be confirmed by in turn looking at the code: the xxx_TERM states
are only ever set in ccid3_hc_{rx,tx}_exit(). These two functions are part
of the following call chain:
* ccid_hc_{tx,rx}_exit() are called from ccid_delete() only;
* ccid_delete() invokes ccid_hc_{tx,rx}_exit() in the way of a destructor:
after calling ccid_hc_{tx,rx}_exit(), the CCID is released from memory;
* ccid_delete() is in turn called only by ccid_hc_{tx,rx}_delete();
* ccid_hc_{tx,rx}_delete() is called only if
- feature negotiation failed (dccp_feat_activate_values()),
- when changing the RX/TX CCID (to eject the current CCID),
- when destroying the socket (in dccp_destroy_sock()).
In other words, when CCID-3 sets the state to xxx_TERM, it is at a time where
no more processing should be going on, hence it is not necessary to introduce
a dedicated exit state - this is implicit when unloading the CCID.
The patch removes this state, one switch-statement collapses as a result.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
} else {
|
2008-09-03 23:30:19 -06:00
|
|
|
delay = ktime_us_delta(hctx->t_nom, now);
|
2007-03-20 11:49:20 -06:00
|
|
|
ccid3_pr_debug("delay=%ld\n", (long)delay);
|
2006-11-27 07:25:10 -07:00
|
|
|
/*
|
2006-12-10 11:01:18 -07:00
|
|
|
* Scheduling of packet transmissions [RFC 3448, 4.6]
|
2006-11-27 07:25:10 -07:00
|
|
|
*
|
|
|
|
|
* if (t_now > t_nom - delta)
|
|
|
|
|
* // send the packet now
|
|
|
|
|
* else
|
|
|
|
|
* // send the packet in (t_nom - t_now) milliseconds.
|
|
|
|
|
*/
|
dccp ccid-3: Bug fix for the inter-packet scheduling algorithm
This fixes a subtle bug in the calculation of the inter-packet gap and shows
that t_delta, as it is currently used, is not needed. And hence replaced.
The algorithm from RFC 3448, 4.6 below continually computes a send time t_nom,
which is initialised with the current time t_now; t_gran = 1E6 / HZ specifies
the scheduling granularity, s the packet size, and X the sending rate:
t_distance = t_nom - t_now; // in microseconds
t_delta = min(t_ipi, t_gran) / 2; // `delta' parameter in microseconds
if (t_distance >= t_delta) {
reschedule after (t_distance / 1000) milliseconds;
} else {
t_ipi = s / X; // inter-packet interval in usec
t_nom += t_ipi; // compute the next send time
send packet now;
}
1) Description of the bug
-------------------------
Rescheduling requires a conversion into milliseconds, due to this call chain:
* ccid3_hc_tx_send_packet() returns a timeout in milliseconds,
* this value is converted by msecs_to_jiffies() in dccp_write_xmit(),
* and finally used as jiffy-expires-value for sk_reset_timer().
The highest jiffy resolution with HZ=1000 is 1 millisecond, so using a higher
granularity does not make much sense here.
As a consequence, values of t_distance < 1000 are truncated to 0. This issue
has so far been resolved by using instead
if (t_distance >= t_delta + 1000)
reschedule after (t_distance / 1000) milliseconds;
The bug is in artificially inflating t_delta to t_delta' = t_delta + 1000. This
is unnecessarily large, a more adequate value is t_delta' = max(t_delta, 1000).
2) Consequences of using the corrected t_delta'
-----------------------------------------------
Since t_delta <= t_gran/2 = 10^6/(2*HZ), we have t_delta <= 1000 as long as
HZ >= 500. This means that t_delta' = max(1000, t_delta) is constant at 1000.
On the other hand, when using a coarse HZ value of HZ < 500, we have three
sub-cases that can all be reduced to using another constant of t_gran/2.
(a) The first case arises when t_ipi > t_gran. Here t_delta' is the constant
t_delta' = max(1000, t_gran/2) = t_gran/2.
(b) If t_ipi <= 2000 < t_gran = 10^6/HZ usec, then t_delta = t_ipi/2 <= 1000,
so that t_delta' = max(1000, t_delta) = 1000 < t_gran/2.
(c) If 2000 < t_ipi <= t_gran, we have t_delta' = max(t_delta, 1000) = t_ipi/2.
In the second and third cases we have delay values less than t_gran/2, which is
in the order of less than or equal to half a jiffy.
How these are treated depends on how fractions of a jiffy are handled: they
are either always rounded down to 0, or always rounded up to 1 jiffy (assuming
non-zero values). In both cases the error is on average in the order of 50%.
Thus we are not increasing the error when in the second/third case we replace
a value less than t_gran/2 with 0, by setting t_delta' to the constant t_gran/2.
3) Summary
----------
Fixing (1) and considering (2), the patch replaces t_delta with a constant,
whose value depends on CONFIG_HZ, changing the above algorithm to:
if (t_distance >= t_delta')
reschedule after (t_distance / 1000) milliseconds;
where t_delta' = 10^6/(2*HZ) if HZ < 500, and t_delta' = 1000 otherwise.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
if (delay >= TFRC_T_DELTA)
|
|
|
|
|
return (u32)delay / USEC_PER_MSEC;
|
2006-12-09 19:07:37 -07:00
|
|
|
|
2007-06-16 10:34:02 -06:00
|
|
|
ccid3_hc_tx_update_win_count(hctx, now);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2006-11-27 07:26:03 -07:00
|
|
|
/* prepare to send now (add options etc.) */
|
|
|
|
|
dp->dccps_hc_tx_insert_options = 1;
|
2008-09-03 23:30:19 -06:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_ccval = hctx->last_win_count;
|
2006-12-09 19:08:09 -07:00
|
|
|
|
|
|
|
|
/* set the nominal send time for the next following packet */
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->t_nom = ktime_add_us(hctx->t_nom, hctx->t_ipi);
|
2008-09-03 23:30:19 -06:00
|
|
|
return CCID_PACKET_SEND_AT_ONCE;
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
static void ccid3_hc_tx_packet_sent(struct sock *sk, unsigned int len)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
dccp ccid-3: Measuring the packet size s with regard to rfc3448bis-06
rfc3448bis allows three different ways of tracking the packet size `s':
1. using the MSS/MPS (at initialisation, 4.2, and in 4.1 (1));
2. using the average of `s' (in 4.1);
3. using the maximum of `s' (in 4.2).
Instead of hard-coding a single interpretation of rfc3448bis, this implements
a choice of all three alternatives and suggests the first as default, since it
is the option which is most consistent with other parts of the specification.
The patch further deprecates the update of t_ipi whenever `s' changes. The
gains of doing this are only small since a change of s takes effect at the
next instant X is updated:
* when the next feedback comes in (within one RTT or less);
* when the nofeedback timer expires (within at most 4 RTTs).
Further, there are complications caused by updating t_ipi whenever s changes:
* if t_ipi had previously been updated to effect oscillation prevention (4.5),
then it is impossible to make the same adjustment to t_ipi again, thus
counter-acting the algorithm;
* s may be updated any time and a modification of t_ipi depends on the current
state (e.g. no oscillation prevention is done in the absence of feedback);
* in rev-06 of rfc3448bis, there are more possible cases, depending on whether
the sender is in slow-start (t_ipi <= R/W_init), or in congestion-avoidance,
limited by X_recv or the throughput equation (t_ipi <= t_mbi).
Thus there are side effects of always updating t_ipi as s changes. These may not
be desirable. The only case I can think of where such an update makes sense is
to recompute X_calc when p > 0 and when s changes (not done by this patch).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-03 23:30:19 -06:00
|
|
|
/* Changes to s will become effective the next time X is computed */
|
|
|
|
|
hctx->s = ccid3_hc_tx_measure_packet_size(sk, len);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
if (tfrc_tx_hist_add(&hctx->hist, dccp_sk(sk)->dccps_gss))
|
[DCCP] ccid3: Perform history operations only after packet has been sent
This migrates all packet history operations into the routine
ccid3_hc_tx_packet_sent, thereby removing synchronization problems
that occur when, as before, the operations are spread over multiple
routines.
The following minor simplifications are also applied:
* several simplifications now follow from this change - several tests
are now no longer required
* removal of one unnecessary variable (dp)
Justification:
Currently packet history operations span two different routines,
one of which is likely to pass through several iterations of sleeping
and awakening.
The first routine, ccid3_hc_tx_send_packet, allocates an entry and
sets a few fields. The remaining fields are filled in when the second
routine (which is not within a sleeping context), ccid3_hc_tx_packet_sent,
is called. This has several strong drawbacks:
* it is not necessary to split history operations - all fields can be
filled in by the second routine
* the first routine is called multiple times, until a packet can be sent,
and sleeps meanwhile - this causes a lot of difficulties with regard to
keeping the list consistent
* since both routines do not have a producer-consumer like synchronization,
it is very difficult to maintain data across calls to these routines
* the fact that the routines are called in different contexts (sleeping, not
sleeping) adds further problems
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
2006-12-09 19:09:21 -07:00
|
|
|
DCCP_CRIT("packet history - out of memory!");
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ccid3_hc_tx_packet_recv(struct sock *sk, struct sk_buff *skb)
|
|
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2008-09-03 23:30:19 -06:00
|
|
|
struct tfrc_tx_hist_entry *acked;
|
2007-08-19 18:18:13 -06:00
|
|
|
ktime_t now;
|
2006-11-28 13:34:34 -07:00
|
|
|
unsigned long t_nfb;
|
2008-09-03 23:30:19 -06:00
|
|
|
u32 r_sample;
|
2005-08-27 00:51:58 -06:00
|
|
|
|
2005-08-09 21:14:34 -06:00
|
|
|
/* we are only interested in ACKs */
|
|
|
|
|
if (!(DCCP_SKB_CB(skb)->dccpd_type == DCCP_PKT_ACK ||
|
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type == DCCP_PKT_DATAACK))
|
|
|
|
|
return;
|
2008-09-03 23:30:19 -06:00
|
|
|
/*
|
|
|
|
|
* Locate the acknowledged packet in the TX history.
|
|
|
|
|
*
|
|
|
|
|
* Returning "entry not found" here can for instance happen when
|
|
|
|
|
* - the host has not sent out anything (e.g. a passive server),
|
|
|
|
|
* - the Ack is outdated (packet with higher Ack number was received),
|
|
|
|
|
* - it is a bogus Ack (for a packet not sent on this connection).
|
|
|
|
|
*/
|
|
|
|
|
acked = tfrc_tx_hist_find_entry(hctx->hist, dccp_hdr_ack_seq(skb));
|
|
|
|
|
if (acked == NULL)
|
2007-12-17 05:25:06 -07:00
|
|
|
return;
|
2008-09-03 23:30:19 -06:00
|
|
|
/* For the sake of RTT sampling, ignore/remove all older entries */
|
|
|
|
|
tfrc_tx_hist_purge(&acked->next);
|
|
|
|
|
|
|
|
|
|
/* Update the moving average for the RTT estimate (RFC 3448, 4.3) */
|
|
|
|
|
now = ktime_get_real();
|
|
|
|
|
r_sample = dccp_sample_rtt(sk, ktime_us_delta(now, acked->stamp));
|
|
|
|
|
hctx->rtt = tfrc_ewma(hctx->rtt, r_sample, 9);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-17 07:48:47 -07:00
|
|
|
/*
|
|
|
|
|
* Update allowed sending rate X as per draft rfc3448bis-00, 4.2/3
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
if (!hctx->feedback) {
|
|
|
|
|
hctx->feedback = true;
|
2006-12-03 09:50:56 -07:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hctx->t_rto == 0) {
|
2007-12-17 07:48:47 -07:00
|
|
|
/*
|
|
|
|
|
* Initial feedback packet: Larger Initial Windows (4.2)
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->x = rfc3390_initial_rate(sk);
|
|
|
|
|
hctx->t_ld = now;
|
2006-11-28 14:51:42 -07:00
|
|
|
|
2007-12-17 07:48:47 -07:00
|
|
|
ccid3_update_send_interval(hctx);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-17 07:48:47 -07:00
|
|
|
goto done_computing_x;
|
2008-09-03 23:30:19 -06:00
|
|
|
} else if (hctx->p == 0) {
|
2007-12-17 07:48:47 -07:00
|
|
|
/*
|
|
|
|
|
* First feedback after nofeedback timer expiry (4.3)
|
|
|
|
|
*/
|
|
|
|
|
goto done_computing_x;
|
|
|
|
|
}
|
|
|
|
|
}
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-17 07:48:47 -07:00
|
|
|
/* Update sending rate (step 4 of [RFC 3448, 4.3]) */
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hctx->p > 0)
|
|
|
|
|
hctx->x_calc = tfrc_calc_x(hctx->s, hctx->rtt, hctx->p);
|
2007-12-17 07:48:47 -07:00
|
|
|
ccid3_hc_tx_update_x(sk, &now);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-17 07:48:47 -07:00
|
|
|
done_computing_x:
|
|
|
|
|
ccid3_pr_debug("%s(%p), RTT=%uus (sample=%uus), s=%u, "
|
2007-12-17 05:25:06 -07:00
|
|
|
"p=%u, X_calc=%u, X_recv=%u, X=%u\n",
|
2008-09-03 23:30:19 -06:00
|
|
|
dccp_role(sk), sk, hctx->rtt, r_sample,
|
|
|
|
|
hctx->s, hctx->p, hctx->x_calc,
|
|
|
|
|
(unsigned)(hctx->x_recv >> 6),
|
|
|
|
|
(unsigned)(hctx->x >> 6));
|
2008-09-03 23:30:19 -06:00
|
|
|
/*
|
|
|
|
|
* Oscillation Reduction (RFC 3448, 4.5) - modifying t_ipi according to
|
|
|
|
|
* RTT changes, multiplying by X/X_inst = sqrt(R_sample)/R_sqmean. This
|
|
|
|
|
* can be useful if few connections share a link, avoiding that buffer
|
|
|
|
|
* fill levels (RTT) oscillate as a result of frequent adjustments to X.
|
|
|
|
|
* A useful presentation with background information is in
|
|
|
|
|
* Joerg Widmer, "Equation-Based Congestion Control",
|
|
|
|
|
* MSc Thesis, University of Mannheim, Germany, 2000
|
|
|
|
|
* (sec. 3.6.4), who calls this ISM ("Inter-packet Space Modulation").
|
|
|
|
|
*/
|
|
|
|
|
if (do_osc_prev) {
|
|
|
|
|
r_sample = tfrc_scaled_sqrt(r_sample);
|
|
|
|
|
/*
|
|
|
|
|
* The modulation can work in both ways: increase/decrease t_ipi
|
|
|
|
|
* according to long-term increases/decreases of the RTT. The
|
|
|
|
|
* former is a useful measure, since it works against queue
|
|
|
|
|
* build-up. The latter temporarily increases the sending rate,
|
|
|
|
|
* so that buffers fill up more quickly. This in turn causes
|
|
|
|
|
* the RTT to increase, so that either later reduction becomes
|
|
|
|
|
* necessary or the RTT stays at a very high level. Decreasing
|
|
|
|
|
* t_ipi is therefore not supported.
|
|
|
|
|
* Furthermore, during the initial slow-start phase the RTT
|
|
|
|
|
* naturally increases, where using the algorithm would cause
|
|
|
|
|
* delays. Hence it is disabled during the initial slow-start.
|
|
|
|
|
*/
|
|
|
|
|
if (r_sample > hctx->r_sqmean && hctx->p > 0)
|
|
|
|
|
hctx->t_ipi = div_u64((u64)hctx->t_ipi * (u64)r_sample,
|
|
|
|
|
hctx->r_sqmean);
|
|
|
|
|
hctx->t_ipi = min_t(u32, hctx->t_ipi, TFRC_T_MBI);
|
|
|
|
|
/* update R_sqmean _after_ computing the modulation factor */
|
|
|
|
|
hctx->r_sqmean = tfrc_ewma(hctx->r_sqmean, r_sample, 9);
|
|
|
|
|
}
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-17 05:25:06 -07:00
|
|
|
/* unschedule no feedback timer */
|
2008-09-03 23:30:19 -06:00
|
|
|
sk_stop_timer(sk, &hctx->no_feedback_timer);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-17 05:25:06 -07:00
|
|
|
/*
|
|
|
|
|
* As we have calculated new ipi, delta, t_nom it is possible
|
|
|
|
|
* that we now can send a packet, so wake up dccp_wait_for_ccid
|
|
|
|
|
*/
|
|
|
|
|
sk->sk_write_space(sk);
|
2005-08-10 09:59:38 -06:00
|
|
|
|
2007-12-17 05:25:06 -07:00
|
|
|
/*
|
|
|
|
|
* Update timeout interval for the nofeedback timer.
|
|
|
|
|
* We use a configuration option to increase the lower bound.
|
|
|
|
|
* This can help avoid triggering the nofeedback timer too
|
|
|
|
|
* often ('spinning') on LANs with small RTTs.
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->t_rto = max_t(u32, 4 * hctx->rtt, (CONFIG_IP_DCCP_CCID3_RTO *
|
|
|
|
|
(USEC_PER_SEC / 1000)));
|
2007-12-17 05:25:06 -07:00
|
|
|
/*
|
|
|
|
|
* Schedule no feedback timer to expire in
|
|
|
|
|
* max(t_RTO, 2 * s/X) = max(t_RTO, 2 * t_ipi)
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
t_nfb = max(hctx->t_rto, 2 * hctx->t_ipi);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-17 05:25:06 -07:00
|
|
|
ccid3_pr_debug("%s(%p), Scheduled no feedback timer to "
|
|
|
|
|
"expire in %lu jiffies (%luus)\n",
|
2008-09-03 23:30:19 -06:00
|
|
|
dccp_role(sk), sk, usecs_to_jiffies(t_nfb), t_nfb);
|
2006-12-09 19:14:12 -07:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
sk_reset_timer(sk, &hctx->no_feedback_timer,
|
2007-12-17 05:25:06 -07:00
|
|
|
jiffies + usecs_to_jiffies(t_nfb));
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
static int ccid3_hc_tx_parse_options(struct sock *sk, u8 packet_type,
|
|
|
|
|
u8 option, u8 *optval, u8 optlen)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2007-10-24 06:46:58 -06:00
|
|
|
__be32 opt_val;
|
2005-08-09 21:14:34 -06:00
|
|
|
|
|
|
|
|
switch (option) {
|
2008-09-03 23:30:19 -06:00
|
|
|
case TFRC_OPT_RECEIVE_RATE:
|
2005-08-09 21:14:34 -06:00
|
|
|
case TFRC_OPT_LOSS_EVENT_RATE:
|
2008-09-03 23:30:19 -06:00
|
|
|
/* Must be ignored on Data packets, cf. RFC 4342 8.3 and 8.5 */
|
|
|
|
|
if (packet_type == DCCP_PKT_DATA)
|
|
|
|
|
break;
|
|
|
|
|
if (unlikely(optlen != 4)) {
|
2008-09-03 23:30:19 -06:00
|
|
|
DCCP_WARN("%s(%p), invalid len %d for %u\n",
|
2008-09-03 23:30:19 -06:00
|
|
|
dccp_role(sk), sk, optlen, option);
|
2008-09-03 23:30:19 -06:00
|
|
|
return -EINVAL;
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
2008-09-03 23:30:19 -06:00
|
|
|
opt_val = ntohl(get_unaligned((__be32 *)optval));
|
2008-09-03 23:30:19 -06:00
|
|
|
|
|
|
|
|
if (option == TFRC_OPT_RECEIVE_RATE) {
|
2008-09-03 23:30:19 -06:00
|
|
|
/* Receive Rate is kept in units of 64 bytes/second */
|
|
|
|
|
hctx->x_recv = opt_val;
|
|
|
|
|
hctx->x_recv <<= 6;
|
|
|
|
|
|
2006-12-09 19:14:12 -07:00
|
|
|
ccid3_pr_debug("%s(%p), RECEIVE_RATE=%u\n",
|
2008-09-03 23:30:19 -06:00
|
|
|
dccp_role(sk), sk, opt_val);
|
|
|
|
|
} else {
|
2008-09-03 23:30:19 -06:00
|
|
|
/* Update the fixpoint Loss Event Rate fraction */
|
|
|
|
|
hctx->p = tfrc_invert_loss_event_rate(opt_val);
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
ccid3_pr_debug("%s(%p), LOSS_EVENT_RATE=%u\n",
|
|
|
|
|
dccp_role(sk), sk, opt_val);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
}
|
2008-09-03 23:30:19 -06:00
|
|
|
return 0;
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2006-03-20 20:21:44 -07:00
|
|
|
static int ccid3_hc_tx_init(struct ccid *ccid, struct sock *sk)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
2006-03-20 20:21:44 -07:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid_priv(ccid);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
hctx->hist = NULL;
|
|
|
|
|
setup_timer(&hctx->no_feedback_timer,
|
|
|
|
|
ccid3_hc_tx_no_feedback_timer, (unsigned long)sk);
|
2005-08-09 21:14:34 -06:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ccid3_hc_tx_exit(struct sock *sk)
|
|
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
sk_stop_timer(sk, &hctx->no_feedback_timer);
|
|
|
|
|
tfrc_tx_hist_purge(&hctx->hist);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2007-03-20 10:11:24 -06:00
|
|
|
static void ccid3_hc_tx_get_info(struct sock *sk, struct tcp_info *info)
|
|
|
|
|
{
|
dccp ccid-3: No more CCID control blocks in LISTEN state
The CCIDs are activated as last of the features, at the end of the handshake,
were the LISTEN state of the master socket is inherited into the server
state of the child socket. Thus, the only states visible to CCIDs now are
OPEN/PARTOPEN, and the closing states.
This allows to remove tests which were previously necessary to protect
against referencing a socket in the listening state (in CCID3), but which
now have become redundant.
As a further byproduct of enabling the CCIDs only after the connection has been
fully established, several typecast-initialisations of ccid3_hc_{rx,tx}_sock
can now be eliminated:
* the CCID is loaded, so it is not necessary to test if it is NULL,
* if it is possible to load a CCID and leave the private area NULL, then this
is a bug, which should crash loudly - and earlier,
* the test for state==OPEN || state==PARTOPEN now reduces only to the closing
phase (e.g. when the node has received an unexpected Reset).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-03 23:30:19 -06:00
|
|
|
info->tcpi_rto = ccid3_hc_tx_sk(sk)->t_rto;
|
|
|
|
|
info->tcpi_rtt = ccid3_hc_tx_sk(sk)->rtt;
|
2007-03-20 10:11:24 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ccid3_hc_tx_getsockopt(struct sock *sk, const int optname, int len,
|
|
|
|
|
u32 __user *optval, int __user *optlen)
|
|
|
|
|
{
|
dccp ccid-3: No more CCID control blocks in LISTEN state
The CCIDs are activated as last of the features, at the end of the handshake,
were the LISTEN state of the master socket is inherited into the server
state of the child socket. Thus, the only states visible to CCIDs now are
OPEN/PARTOPEN, and the closing states.
This allows to remove tests which were previously necessary to protect
against referencing a socket in the listening state (in CCID3), but which
now have become redundant.
As a further byproduct of enabling the CCIDs only after the connection has been
fully established, several typecast-initialisations of ccid3_hc_{rx,tx}_sock
can now be eliminated:
* the CCID is loaded, so it is not necessary to test if it is NULL,
* if it is possible to load a CCID and leave the private area NULL, then this
is a bug, which should crash loudly - and earlier,
* the test for state==OPEN || state==PARTOPEN now reduces only to the closing
phase (e.g. when the node has received an unexpected Reset).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-03 23:30:19 -06:00
|
|
|
const struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
|
2008-09-03 23:30:19 -06:00
|
|
|
struct tfrc_tx_info tfrc;
|
2007-03-20 10:11:24 -06:00
|
|
|
const void *val;
|
|
|
|
|
|
|
|
|
|
switch (optname) {
|
|
|
|
|
case DCCP_SOCKOPT_CCID_TX_INFO:
|
2008-09-03 23:30:19 -06:00
|
|
|
if (len < sizeof(tfrc))
|
2007-03-20 10:11:24 -06:00
|
|
|
return -EINVAL;
|
2008-09-03 23:30:19 -06:00
|
|
|
tfrc.tfrctx_x = hctx->x;
|
|
|
|
|
tfrc.tfrctx_x_recv = hctx->x_recv;
|
|
|
|
|
tfrc.tfrctx_x_calc = hctx->x_calc;
|
|
|
|
|
tfrc.tfrctx_rtt = hctx->rtt;
|
|
|
|
|
tfrc.tfrctx_p = hctx->p;
|
|
|
|
|
tfrc.tfrctx_rto = hctx->t_rto;
|
|
|
|
|
tfrc.tfrctx_ipi = hctx->t_ipi;
|
|
|
|
|
len = sizeof(tfrc);
|
|
|
|
|
val = &tfrc;
|
2007-03-20 10:11:24 -06:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (put_user(len, optlen) || copy_to_user(optval, val, len))
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-09 21:14:34 -06:00
|
|
|
/*
|
2007-03-20 10:11:24 -06:00
|
|
|
* Receiver Half-Connection Routines
|
2005-08-09 21:14:34 -06:00
|
|
|
*/
|
2007-12-06 08:18:11 -07:00
|
|
|
static void ccid3_hc_rx_send_feedback(struct sock *sk,
|
|
|
|
|
const struct sk_buff *skb,
|
|
|
|
|
enum ccid3_fback_type fbtype)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_rx_sock *hcrx = ccid3_hc_rx_sk(sk);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2007-12-06 08:18:11 -07:00
|
|
|
switch (fbtype) {
|
|
|
|
|
case CCID3_FBACK_INITIAL:
|
2008-09-03 23:30:19 -06:00
|
|
|
hcrx->x_recv = 0;
|
|
|
|
|
hcrx->p_inverse = ~0U; /* see RFC 4342, 8.5 */
|
2005-08-09 21:14:34 -06:00
|
|
|
break;
|
2007-12-06 08:18:11 -07:00
|
|
|
case CCID3_FBACK_PARAM_CHANGE:
|
2008-09-03 23:30:19 -06:00
|
|
|
if (unlikely(hcrx->feedback == CCID3_FBACK_NONE)) {
|
2008-09-03 23:30:19 -06:00
|
|
|
/*
|
|
|
|
|
* rfc3448bis-06, 6.3.1: First packet(s) lost or marked
|
|
|
|
|
* FIXME: in rfc3448bis the receiver returns X_recv=0
|
|
|
|
|
* here as it normally would in the first feedback packet.
|
|
|
|
|
* However this is not possible yet, since the code still
|
|
|
|
|
* uses RFC 3448, i.e.
|
|
|
|
|
* If (p > 0)
|
|
|
|
|
* Calculate X_calc using the TCP throughput equation.
|
|
|
|
|
* X = max(min(X_calc, 2*X_recv), s/t_mbi);
|
|
|
|
|
* would bring X down to s/t_mbi. That is why we return
|
|
|
|
|
* X_recv according to rfc3448bis-06 for the moment.
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
u32 s = tfrc_rx_hist_packet_size(&hcrx->hist),
|
|
|
|
|
rtt = tfrc_rx_hist_rtt(&hcrx->hist);
|
2008-09-03 23:30:19 -06:00
|
|
|
|
|
|
|
|
hcrx->x_recv = scaled_div32(s, 2 * rtt);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2007-12-06 08:18:11 -07:00
|
|
|
/*
|
|
|
|
|
* When parameters change (new loss or p > p_prev), we do not
|
|
|
|
|
* have a reliable estimate for R_m of [RFC 3448, 6.2] and so
|
2008-09-03 23:30:19 -06:00
|
|
|
* always check whether at least RTT time units were covered.
|
2007-12-06 08:18:11 -07:00
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
hcrx->x_recv = tfrc_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
|
|
|
|
|
break;
|
2007-12-06 08:18:11 -07:00
|
|
|
case CCID3_FBACK_PERIODIC:
|
2008-09-03 23:30:19 -06:00
|
|
|
/*
|
2008-09-03 23:30:19 -06:00
|
|
|
* Step (2) of rfc3448bis-06, 6.2:
|
|
|
|
|
* - if no data packets have been received, just restart timer
|
|
|
|
|
* - if data packets have been received, re-compute X_recv
|
2008-09-03 23:30:19 -06:00
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
if (hcrx->hist.bytes_recvd == 0)
|
|
|
|
|
goto prepare_for_next_time;
|
|
|
|
|
hcrx->x_recv = tfrc_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
|
2005-08-09 21:14:34 -06:00
|
|
|
break;
|
2007-12-06 08:18:11 -07:00
|
|
|
default:
|
2005-08-09 21:14:34 -06:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
ccid3_pr_debug("X_recv=%u, 1/p=%u\n", hcrx->x_recv, hcrx->p_inverse);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
dccp_sk(sk)->dccps_hc_rx_insert_options = 1;
|
2005-08-09 21:14:34 -06:00
|
|
|
dccp_send_ack(sk);
|
2008-09-03 23:30:19 -06:00
|
|
|
|
|
|
|
|
prepare_for_next_time:
|
|
|
|
|
tfrc_rx_hist_restart_byte_counter(&hcrx->hist);
|
|
|
|
|
hcrx->last_counter = dccp_hdr(skb)->dccph_ccval;
|
|
|
|
|
hcrx->feedback = fbtype;
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2006-03-20 23:32:06 -07:00
|
|
|
static int ccid3_hc_rx_insert_options(struct sock *sk, struct sk_buff *skb)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
dccp ccid-3: No more CCID control blocks in LISTEN state
The CCIDs are activated as last of the features, at the end of the handshake,
were the LISTEN state of the master socket is inherited into the server
state of the child socket. Thus, the only states visible to CCIDs now are
OPEN/PARTOPEN, and the closing states.
This allows to remove tests which were previously necessary to protect
against referencing a socket in the listening state (in CCID3), but which
now have become redundant.
As a further byproduct of enabling the CCIDs only after the connection has been
fully established, several typecast-initialisations of ccid3_hc_{rx,tx}_sock
can now be eliminated:
* the CCID is loaded, so it is not necessary to test if it is NULL,
* if it is possible to load a CCID and leave the private area NULL, then this
is a bug, which should crash loudly - and earlier,
* the test for state==OPEN || state==PARTOPEN now reduces only to the closing
phase (e.g. when the node has received an unexpected Reset).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-03 23:30:19 -06:00
|
|
|
const struct ccid3_hc_rx_sock *hcrx = ccid3_hc_rx_sk(sk);
|
2006-03-20 20:23:32 -07:00
|
|
|
__be32 x_recv, pinv;
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2005-09-09 17:01:25 -06:00
|
|
|
if (!(sk->sk_state == DCCP_OPEN || sk->sk_state == DCCP_PARTOPEN))
|
2006-03-20 23:32:06 -07:00
|
|
|
return 0;
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2005-08-23 22:51:59 -06:00
|
|
|
if (dccp_packet_without_ack(skb))
|
2006-03-20 23:32:06 -07:00
|
|
|
return 0;
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
x_recv = htonl(hcrx->x_recv);
|
|
|
|
|
pinv = htonl(hcrx->p_inverse);
|
2006-03-20 23:32:06 -07:00
|
|
|
|
2007-12-08 11:26:59 -07:00
|
|
|
if (dccp_insert_option(sk, skb, TFRC_OPT_LOSS_EVENT_RATE,
|
2006-12-10 11:01:18 -07:00
|
|
|
&pinv, sizeof(pinv)) ||
|
2006-03-20 23:32:06 -07:00
|
|
|
dccp_insert_option(sk, skb, TFRC_OPT_RECEIVE_RATE,
|
2006-12-10 11:01:18 -07:00
|
|
|
&x_recv, sizeof(x_recv)))
|
2006-03-20 23:32:06 -07:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
return 0;
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2007-12-12 09:06:14 -07:00
|
|
|
/** ccid3_first_li - Implements [RFC 3448, 6.3.1]
|
|
|
|
|
*
|
|
|
|
|
* Determine the length of the first loss interval via inverse lookup.
|
|
|
|
|
* Assume that X_recv can be computed by the throughput equation
|
|
|
|
|
* s
|
|
|
|
|
* X_recv = --------
|
|
|
|
|
* R * fval
|
|
|
|
|
* Find some p such that f(p) = fval; return 1/p (scaled).
|
|
|
|
|
*/
|
|
|
|
|
static u32 ccid3_first_li(struct sock *sk)
|
|
|
|
|
{
|
|
|
|
|
struct ccid3_hc_rx_sock *hcrx = ccid3_hc_rx_sk(sk);
|
2008-09-03 23:30:19 -06:00
|
|
|
u32 s = tfrc_rx_hist_packet_size(&hcrx->hist),
|
2008-09-03 23:30:19 -06:00
|
|
|
rtt = tfrc_rx_hist_rtt(&hcrx->hist), x_recv, p;
|
2007-12-12 09:06:14 -07:00
|
|
|
u64 fval;
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
/*
|
|
|
|
|
* rfc3448bis-06, 6.3.1: First data packet(s) are marked or lost. Set p
|
|
|
|
|
* to give the equivalent of X_target = s/(2*R). Thus fval = 2 and so p
|
|
|
|
|
* is about 20.64%. This yields an interval length of 4.84 (rounded up).
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
if (unlikely(hcrx->feedback == CCID3_FBACK_NONE))
|
2008-09-03 23:30:19 -06:00
|
|
|
return 5;
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
x_recv = tfrc_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
|
|
|
|
|
if (x_recv == 0)
|
|
|
|
|
goto failed;
|
2007-12-12 09:06:14 -07:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
fval = scaled_div32(scaled_div(s, rtt), x_recv);
|
2007-12-12 09:06:14 -07:00
|
|
|
p = tfrc_calc_x_reverse_lookup(fval);
|
|
|
|
|
|
|
|
|
|
ccid3_pr_debug("%s(%p), receive rate=%u bytes/s, implied "
|
|
|
|
|
"loss rate=%u\n", dccp_role(sk), sk, x_recv, p);
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
if (p > 0)
|
|
|
|
|
return scaled_div(1, p);
|
|
|
|
|
failed:
|
|
|
|
|
return UINT_MAX;
|
2007-12-12 09:06:14 -07:00
|
|
|
}
|
|
|
|
|
|
2007-12-06 08:18:11 -07:00
|
|
|
static void ccid3_hc_rx_packet_recv(struct sock *sk, struct sk_buff *skb)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_rx_sock *hcrx = ccid3_hc_rx_sk(sk);
|
2008-07-13 04:51:40 -06:00
|
|
|
const u64 ndp = dccp_sk(sk)->dccps_options_received.dccpor_ndp;
|
2007-12-06 08:18:11 -07:00
|
|
|
const bool is_data_packet = dccp_data_packet(skb);
|
|
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
/*
|
|
|
|
|
* Perform loss detection and handle pending losses
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
if (tfrc_rx_congestion_event(&hcrx->hist, &hcrx->li_hist,
|
|
|
|
|
skb, ndp, ccid3_first_li, sk))
|
|
|
|
|
ccid3_hc_rx_send_feedback(sk, skb, CCID3_FBACK_PARAM_CHANGE);
|
|
|
|
|
/*
|
|
|
|
|
* Feedback for first non-empty data packet (RFC 3448, 6.3)
|
|
|
|
|
*/
|
|
|
|
|
else if (unlikely(hcrx->feedback == CCID3_FBACK_NONE && is_data_packet))
|
|
|
|
|
ccid3_hc_rx_send_feedback(sk, skb, CCID3_FBACK_INITIAL);
|
2007-12-06 08:18:11 -07:00
|
|
|
/*
|
|
|
|
|
* Check if the periodic once-per-RTT feedback is due; RFC 4342, 10.3
|
|
|
|
|
*/
|
2008-09-03 23:30:19 -06:00
|
|
|
else if (!tfrc_rx_hist_loss_pending(&hcrx->hist) && is_data_packet &&
|
|
|
|
|
SUB16(dccp_hdr(skb)->dccph_ccval, hcrx->last_counter) > 3)
|
|
|
|
|
ccid3_hc_rx_send_feedback(sk, skb, CCID3_FBACK_PERIODIC);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
2006-03-20 20:21:44 -07:00
|
|
|
static int ccid3_hc_rx_init(struct ccid *ccid, struct sock *sk)
|
2005-08-09 21:14:34 -06:00
|
|
|
{
|
2006-03-20 20:21:44 -07:00
|
|
|
struct ccid3_hc_rx_sock *hcrx = ccid_priv(ccid);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
tfrc_lh_init(&hcrx->li_hist);
|
2008-09-03 23:30:19 -06:00
|
|
|
return tfrc_rx_hist_init(&hcrx->hist, sk);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ccid3_hc_rx_exit(struct sock *sk)
|
|
|
|
|
{
|
2005-09-08 23:40:58 -06:00
|
|
|
struct ccid3_hc_rx_sock *hcrx = ccid3_hc_rx_sk(sk);
|
2005-08-09 21:14:34 -06:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
tfrc_rx_hist_purge(&hcrx->hist);
|
|
|
|
|
tfrc_lh_cleanup(&hcrx->li_hist);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-23 22:52:35 -06:00
|
|
|
static void ccid3_hc_rx_get_info(struct sock *sk, struct tcp_info *info)
|
|
|
|
|
{
|
2006-12-10 11:01:18 -07:00
|
|
|
info->tcpi_options |= TCPI_OPT_TIMESTAMPS;
|
2008-09-03 23:30:19 -06:00
|
|
|
info->tcpi_rcv_rtt = tfrc_rx_hist_rtt(&ccid3_hc_rx_sk(sk)->hist);
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-23 22:52:35 -06:00
|
|
|
}
|
|
|
|
|
|
2005-09-18 01:19:32 -06:00
|
|
|
static int ccid3_hc_rx_getsockopt(struct sock *sk, const int optname, int len,
|
|
|
|
|
u32 __user *optval, int __user *optlen)
|
|
|
|
|
{
|
dccp ccid-3: No more CCID control blocks in LISTEN state
The CCIDs are activated as last of the features, at the end of the handshake,
were the LISTEN state of the master socket is inherited into the server
state of the child socket. Thus, the only states visible to CCIDs now are
OPEN/PARTOPEN, and the closing states.
This allows to remove tests which were previously necessary to protect
against referencing a socket in the listening state (in CCID3), but which
now have become redundant.
As a further byproduct of enabling the CCIDs only after the connection has been
fully established, several typecast-initialisations of ccid3_hc_{rx,tx}_sock
can now be eliminated:
* the CCID is loaded, so it is not necessary to test if it is NULL,
* if it is possible to load a CCID and leave the private area NULL, then this
is a bug, which should crash loudly - and earlier,
* the test for state==OPEN || state==PARTOPEN now reduces only to the closing
phase (e.g. when the node has received an unexpected Reset).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-03 23:30:19 -06:00
|
|
|
const struct ccid3_hc_rx_sock *hcrx = ccid3_hc_rx_sk(sk);
|
2007-12-17 05:07:44 -07:00
|
|
|
struct tfrc_rx_info rx_info;
|
2005-09-18 01:19:32 -06:00
|
|
|
const void *val;
|
2007-02-09 07:24:38 -07:00
|
|
|
|
2005-09-18 01:19:32 -06:00
|
|
|
switch (optname) {
|
|
|
|
|
case DCCP_SOCKOPT_CCID_RX_INFO:
|
2007-12-17 05:07:44 -07:00
|
|
|
if (len < sizeof(rx_info))
|
2005-09-18 01:19:32 -06:00
|
|
|
return -EINVAL;
|
2008-09-03 23:30:19 -06:00
|
|
|
rx_info.tfrcrx_x_recv = hcrx->x_recv;
|
2008-09-03 23:30:19 -06:00
|
|
|
rx_info.tfrcrx_rtt = tfrc_rx_hist_rtt(&hcrx->hist);
|
2008-09-03 23:30:19 -06:00
|
|
|
rx_info.tfrcrx_p = tfrc_invert_loss_event_rate(hcrx->p_inverse);
|
2007-12-17 05:07:44 -07:00
|
|
|
len = sizeof(rx_info);
|
|
|
|
|
val = &rx_info;
|
2005-09-18 01:19:32 -06:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (put_user(len, optlen) || copy_to_user(optval, val, len))
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-03-20 20:21:44 -07:00
|
|
|
static struct ccid_operations ccid3 = {
|
2006-09-21 20:26:44 -06:00
|
|
|
.ccid_id = DCCPC_CCID3,
|
2007-12-13 18:33:25 -07:00
|
|
|
.ccid_name = "TCP-Friendly Rate Control",
|
2005-08-09 21:14:34 -06:00
|
|
|
.ccid_owner = THIS_MODULE,
|
2006-03-20 20:21:44 -07:00
|
|
|
.ccid_hc_tx_obj_size = sizeof(struct ccid3_hc_tx_sock),
|
2005-08-09 21:14:34 -06:00
|
|
|
.ccid_hc_tx_init = ccid3_hc_tx_init,
|
|
|
|
|
.ccid_hc_tx_exit = ccid3_hc_tx_exit,
|
|
|
|
|
.ccid_hc_tx_send_packet = ccid3_hc_tx_send_packet,
|
|
|
|
|
.ccid_hc_tx_packet_sent = ccid3_hc_tx_packet_sent,
|
|
|
|
|
.ccid_hc_tx_packet_recv = ccid3_hc_tx_packet_recv,
|
|
|
|
|
.ccid_hc_tx_parse_options = ccid3_hc_tx_parse_options,
|
2006-03-20 20:21:44 -07:00
|
|
|
.ccid_hc_rx_obj_size = sizeof(struct ccid3_hc_rx_sock),
|
2005-08-09 21:14:34 -06:00
|
|
|
.ccid_hc_rx_init = ccid3_hc_rx_init,
|
|
|
|
|
.ccid_hc_rx_exit = ccid3_hc_rx_exit,
|
|
|
|
|
.ccid_hc_rx_insert_options = ccid3_hc_rx_insert_options,
|
|
|
|
|
.ccid_hc_rx_packet_recv = ccid3_hc_rx_packet_recv,
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-23 22:52:35 -06:00
|
|
|
.ccid_hc_rx_get_info = ccid3_hc_rx_get_info,
|
|
|
|
|
.ccid_hc_tx_get_info = ccid3_hc_tx_get_info,
|
2005-09-18 01:19:32 -06:00
|
|
|
.ccid_hc_rx_getsockopt = ccid3_hc_rx_getsockopt,
|
|
|
|
|
.ccid_hc_tx_getsockopt = ccid3_hc_tx_getsockopt,
|
2005-08-09 21:14:34 -06:00
|
|
|
};
|
2006-12-10 11:01:18 -07:00
|
|
|
|
2008-09-03 23:30:19 -06:00
|
|
|
module_param(do_osc_prev, bool, 0644);
|
|
|
|
|
MODULE_PARM_DESC(do_osc_prev, "Use Oscillation Prevention (RFC 3448, 4.5)");
|
|
|
|
|
|
2006-11-20 13:28:09 -07:00
|
|
|
#ifdef CONFIG_IP_DCCP_CCID3_DEBUG
|
2008-08-23 05:28:27 -06:00
|
|
|
module_param(ccid3_debug, bool, 0644);
|
2005-08-09 21:14:34 -06:00
|
|
|
MODULE_PARM_DESC(ccid3_debug, "Enable debug messages");
|
2006-11-20 13:28:09 -07:00
|
|
|
#endif
|
2005-08-09 21:14:34 -06:00
|
|
|
|
|
|
|
|
static __init int ccid3_module_init(void)
|
|
|
|
|
{
|
2008-09-03 23:30:19 -06:00
|
|
|
struct timespec tp;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Without a fine-grained clock resolution, RTTs/X_recv are not sampled
|
|
|
|
|
* correctly and feedback is sent either too early or too late.
|
|
|
|
|
*/
|
|
|
|
|
hrtimer_get_res(CLOCK_MONOTONIC, &tp);
|
|
|
|
|
if (tp.tv_sec || tp.tv_nsec > DCCP_TIME_RESOLUTION * NSEC_PER_USEC) {
|
|
|
|
|
printk(KERN_ERR "%s: Timer too coarse (%ld usec), need %u-usec"
|
|
|
|
|
" resolution - check your clocksource.\n", __func__,
|
|
|
|
|
tp.tv_nsec/NSEC_PER_USEC, DCCP_TIME_RESOLUTION);
|
|
|
|
|
return -ESOCKTNOSUPPORT;
|
|
|
|
|
}
|
2007-12-06 07:28:13 -07:00
|
|
|
return ccid_register(&ccid3);
|
2005-08-09 21:14:34 -06:00
|
|
|
}
|
|
|
|
|
module_init(ccid3_module_init);
|
|
|
|
|
|
|
|
|
|
static __exit void ccid3_module_exit(void)
|
|
|
|
|
{
|
|
|
|
|
ccid_unregister(&ccid3);
|
|
|
|
|
}
|
|
|
|
|
module_exit(ccid3_module_exit);
|
|
|
|
|
|
2006-08-26 20:01:30 -06:00
|
|
|
MODULE_AUTHOR("Ian McDonald <ian.mcdonald@jandi.co.nz>, "
|
2005-08-27 00:51:58 -06:00
|
|
|
"Arnaldo Carvalho de Melo <acme@ghostprotocols.net>");
|
2005-08-09 21:14:34 -06:00
|
|
|
MODULE_DESCRIPTION("DCCP TFRC CCID3 CCID");
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
MODULE_ALIAS("net-dccp-ccid-3");
|
