From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Conditions when t_ipi, t_nom, t_delta need to be recalculated
Date: Thu, 23 Nov 2006 13:02:44 +0000 [thread overview]
Message-ID: <200611231302.45475@strip-the-willow> (raw)
"When is it necessary to update t_ipi, t_delta, t_nom" ?
=============================
Following Ian's email from yesterday, I spent time working through the RFCs and
compiled information about the dependencies among the different parameters. This
email is a write-up of what I found and serves as basis for subsequent patches.
The parameters are:
s: sender packet size in bytes, known to sender
X: current sending rate (bytes/second), known to sender
p : loss event rate, undefined until feedback has been received
t_RTT : round-trip time estimate, undefined until feedback has been received
t_RTO : retransmission timeout, undefined until feedback has been received
X_calc: = f(s, p, t_RTT) - also undefined until feedback has been received
X_inst: instantaneous xmit rate, f(X) - undefined until feedback has been received
t_nfb: nofeedback time-out, known to sender
t_tld: time-last-doubled, -1 until first packet has been sent
1) Definition of t_ipi
----------------------
In [RFC 3448, 4.6], t_ipi is defined as t_ipi = s/X_inst
If the feature `Preventing Oscillations' [RFC 3448, 4.5] is not implemented, then X_inst = X.
Otherwise, X_inst depends on the feedback sample for t_RTT and is undefined until the first feedback
has arrived. The assumption here is that the optional `Preventing Oscillations' feature is not
implemented, as it requires square-root computation which is complicated without floating-point
arithmetic. Then,
t_ipi = s/X
and X can be (1) the initial value or (2) the recalculated value after feedback has been received.
Hence t_ipi needs to be updated whenever
(i) s changes
(ii) X changes
To simplify, we assume that `s' is fixed and therefore t_ipi only needs to be updated whenever X changes.
However, in the actual patch (which tracks the mean value of the packet size in `s'), a note will be added
as a possibility for further optimisation (it is also not implemented since the standard is silent about
whether the t_ipi should be updated whenever the mean value `s' changes).
2) What depends on t_ipi
------------------------
The following values are derived from and thus depend on t_ipi [RFC 3448, 4.6]:
* nominal sending time: t_nom = t_(i+1) + t_ipi
* scheduling delta : t_delta = min(t_ipi/2, t_gran/2)
Another dependency is the nofeedback timer: after initial feedback has been received, it is set to
t_nfb = max(4*t_RTT, 2 * s/X)
= max(4*t_RTT, 2 * t_ipi)
Thus these three values, in turn, need to be updated when t_ipi changes.
3) Initial values
-----------------
Initial settings are described in [RFC 3448, 4.2]:
X/s = 1hz
t_RTT, t_RTO are undefined
t_tld = -1
Thus we have the following initial values:
t_ipi = s/X = 1 second
t_nom = t_now + t_ipi
t_delta = t_gran/2 (since OS schedules finer than 1 second)
==> A patch has already been sent for this case.
4) Sending until the first feedback packet arrives
--------------------------------------------------
No need to update: X, t_ipi, t_delta, t_nfb stay at their values, t_nom is incremented in the manner
t_nom += t_ipi [where t_ipi remains constant]
=> This is already implemented by ccid3_hc_tx_send_packet
5) When the first feedback packet arrives
-----------------------------------------
The first feedback packet sent by a receiver has p = X_recv = 0 [RFC 3448, 6.3]. Plugging these values
into step (4) of [RFC 3448, 4.3] and considering t_tld = -1, gives
X = max(2 * min(X, X_recv), s/R)
= max(2 * min(X, 0), s/R) = s/R
Without modification, the first sending rate remains at 1 packet per round-trip time. [RFC 4342, sec. 5]
increases this to 2 * s/R, up to the maximum of 4 packets per RTT and 4380 per RTT (this assumes that MSS-sized
packets are sent).
==> A patch is required to consider this special case.
6) When the second ... n-th feedback arrives
--------------------------------------------
X, t_ipi, t_delta, t_nfb, t_nom need to be updated.
==> This is already handled by ccid3_hc_tx_packet_recv.
7) When the nofeedback timer expires and no feedback has been received so far (step 4.4)
----------------------------------------------------------------------------------------
X = max(X/2, s/t_mbi)
--> t_ipi, t_nom, t_delta must be recalculated
t_nfb = max(4*t_RTT, 2*t_ipi)
==> This needs updating, there is a FIXME in ccid3_hc_tx_no_feedback_timer at this place.
8) When the nofeedback timer expires and feedback has been received previously (step 4.4)
-----------------------------------------------------------------------------------------
* t_RTT, t_RTO, and p do not change with regard to the last-received feedback
* thus X_calc is as before
* X_recv gets changed
* hence X gets changed as a result of step (4) of [RFC 3448, 4.3]
--> t_ipi, t_nom, t_delta, and t_nfb need to be updated
==> This also needs a patch, since X is updated, but t_ipi, t_nom, and t_delta are not
next reply other threads:[~2006-11-23 13:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-23 13:02 Gerrit Renker [this message]
2006-11-23 13:06 ` Conditions when t_ipi, t_nom, t_delta need to be recalculated Gerrit Renker
2006-11-23 19:29 ` Ian McDonald
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=200611231302.45475@strip-the-willow \
--to=gerrit@erg.abdn.ac.uk \
--cc=dccp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.