c8f41d50ad
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>
138 lines
5.0 KiB
Plaintext
138 lines
5.0 KiB
Plaintext
menu "DCCP CCIDs Configuration (EXPERIMENTAL)"
|
|
|
|
config IP_DCCP_CCID2
|
|
tristate "CCID2 (TCP-Like)"
|
|
def_tristate IP_DCCP
|
|
---help---
|
|
CCID 2, TCP-like Congestion Control, denotes Additive Increase,
|
|
Multiplicative Decrease (AIMD) congestion control with behavior
|
|
modelled directly on TCP, including congestion window, slow start,
|
|
timeouts, and so forth [RFC 2581]. CCID 2 achieves maximum
|
|
bandwidth over the long term, consistent with the use of end-to-end
|
|
congestion control, but halves its congestion window in response to
|
|
each congestion event. This leads to the abrupt rate changes
|
|
typical of TCP. Applications should use CCID 2 if they prefer
|
|
maximum bandwidth utilization to steadiness of rate. This is often
|
|
the case for applications that are not playing their data directly
|
|
to the user. For example, a hypothetical application that
|
|
transferred files over DCCP, using application-level retransmissions
|
|
for lost packets, would prefer CCID 2 to CCID 3. On-line games may
|
|
also prefer CCID 2. See RFC 4341 for further details.
|
|
|
|
CCID2 is the default CCID used by DCCP.
|
|
|
|
config IP_DCCP_CCID2_DEBUG
|
|
bool "CCID2 debugging messages"
|
|
depends on IP_DCCP_CCID2
|
|
---help---
|
|
Enable CCID2-specific debugging messages.
|
|
|
|
When compiling CCID2 as a module, this debugging output can
|
|
additionally be toggled by setting the ccid2_debug module
|
|
parameter to 0 or 1.
|
|
|
|
If in doubt, say N.
|
|
|
|
config IP_DCCP_CCID3
|
|
tristate "CCID3 (TCP-Friendly)"
|
|
def_tristate IP_DCCP
|
|
select IP_DCCP_TFRC_LIB
|
|
---help---
|
|
CCID 3 denotes TCP-Friendly Rate Control (TFRC), an equation-based
|
|
rate-controlled congestion control mechanism. TFRC is designed to
|
|
be reasonably fair when competing for bandwidth with TCP-like flows,
|
|
where a flow is "reasonably fair" if its sending rate is generally
|
|
within a factor of two of the sending rate of a TCP flow under the
|
|
same conditions. However, TFRC has a much lower variation of
|
|
throughput over time compared with TCP, which makes CCID 3 more
|
|
suitable than CCID 2 for applications such streaming media where a
|
|
relatively smooth sending rate is of importance.
|
|
|
|
CCID 3 is further described in RFC 4342,
|
|
http://www.ietf.org/rfc/rfc4342.txt
|
|
|
|
The TFRC congestion control algorithms were initially described in
|
|
RFC 3448.
|
|
|
|
This text was extracted from RFC 4340 (sec. 10.2),
|
|
http://www.ietf.org/rfc/rfc4340.txt
|
|
|
|
To compile this CCID as a module, choose M here: the module will be
|
|
called dccp_ccid3.
|
|
|
|
If in doubt, say M.
|
|
|
|
if IP_DCCP_CCID3
|
|
config IP_DCCP_CCID3_DEBUG
|
|
bool "CCID3 debugging messages"
|
|
---help---
|
|
Enable CCID3-specific debugging messages.
|
|
|
|
When compiling CCID3 as a module, this debugging output can
|
|
additionally be toggled by setting the ccid3_debug module
|
|
parameter to 0 or 1.
|
|
|
|
If in doubt, say N.
|
|
|
|
choice
|
|
prompt "Select method for measuring the packet size s"
|
|
default IP_DCCP_CCID3_MEASURE_S_AS_MPS
|
|
|
|
config IP_DCCP_CCID3_MEASURE_S_AS_MPS
|
|
bool "Always use MPS in place of s"
|
|
---help---
|
|
This use is recommended as it is consistent with the initialisation
|
|
of X and suggested when s varies (rfc3448bis, (1) in section 4.1).
|
|
config IP_DCCP_CCID3_MEASURE_S_AS_AVG
|
|
bool "Use moving average"
|
|
---help---
|
|
An alternative way of tracking s, also supported by rfc3448bis.
|
|
This used to be the default for CCID-3 in previous kernels.
|
|
config IP_DCCP_CCID3_MEASURE_S_AS_MAX
|
|
bool "Track the maximum payload length"
|
|
---help---
|
|
An experimental method based on tracking the maximum packet size.
|
|
endchoice
|
|
|
|
config IP_DCCP_CCID3_RTO
|
|
int "Use higher bound for nofeedback timer"
|
|
default 100
|
|
---help---
|
|
Use higher lower bound for nofeedback timer expiration.
|
|
|
|
The TFRC nofeedback timer normally expires after the maximum of 4
|
|
RTTs and twice the current send interval (RFC 3448, 4.3). On LANs
|
|
with a small RTT this can mean a high processing load and reduced
|
|
performance, since then the nofeedback timer is triggered very
|
|
frequently.
|
|
|
|
This option enables to set a higher lower bound for the nofeedback
|
|
value. Values in units of milliseconds can be set here.
|
|
|
|
A value of 0 disables this feature by enforcing the value specified
|
|
in RFC 3448. The following values have been suggested as bounds for
|
|
experimental use:
|
|
* 16-20ms to match the typical multimedia inter-frame interval
|
|
* 100ms as a reasonable compromise [default]
|
|
* 1000ms corresponds to the lower TCP RTO bound (RFC 2988, 2.4)
|
|
|
|
The default of 100ms is a compromise between a large value for
|
|
efficient DCCP implementations, and a small value to avoid disrupting
|
|
the network in times of congestion.
|
|
|
|
The purpose of the nofeedback timer is to slow DCCP down when there
|
|
is serious network congestion: experimenting with larger values should
|
|
therefore not be performed on WANs.
|
|
endif # IP_DCCP_CCID3
|
|
|
|
config IP_DCCP_TFRC_LIB
|
|
tristate
|
|
default n
|
|
|
|
config IP_DCCP_TFRC_DEBUG
|
|
bool
|
|
depends on IP_DCCP_TFRC_LIB
|
|
default y if IP_DCCP_CCID3_DEBUG
|
|
|
|
endmenu
|