DCCP protocol discussions
 help / color / mirror / Atom feed
From: "Arnaldo Carvalho de Melo" <arnaldo.melo@gmail.com>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 2/6]: Simplify control flow in the calculation of t_ipi
Date: Sun, 26 Nov 2006 17:37:41 +0000	[thread overview]
Message-ID: <39e6f6c70611260937tabed33fr8fe46bbb6573fcb6@mail.gmail.com> (raw)
In-Reply-To: <200611211545.18544@strip-the-willow>

On 11/26/06, Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> On 11/21/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> > [CCID 3]: Simplify control flow in the calculation of t_ipi
> >
> >
> > This patch performs a simplifying (performance) optimisation:
> >
> >  In each call of the inline function ccid3_calc_new_t_ipi(), the state is
> >  tested against TFRC_SSTATE_NO_FBACK. This is expensive when the function
> >  is called very often. A simpler solution, implemented by this patch, is
> >  to adapt the control flow.
> >
> > Background:
> > -----------
> >  Upon sender initialisation, the values of t_ipi, t_nom = t_0, delta, as
> >  well as the initial packet sending rate, are all constants [RFC 3448, 4.2].
> >  Until feedback arrives, these values are not changed. Hence it is not necessary
> >  to recalculate t_ipi, t_nom, delta until the first feedback has arrived, i.e.
> >  as long as the state TFRC_SSTATE_NO_FBACK persists.
> >
> > Justification:
> > --------------
> >  ccid3_calc_new_t_ipi() is called only in two places:
> >
> >    * in ccid3_hc_tx_packet_recv(); here the state is never TFRC_SSTATE_NO_FBACK, due to
> >         if (hctx->ccid3hctx_state = TFRC_SSTATE_NO_FBACK) {
> >                 ccid3_hc_tx_set_state(sk, TFRC_SSTATE_FBACK);
> >                 /* ... */
> >    * in ccid3_hc_tx_packet_sent()
> >
> >  => Only in the second case, the state might be TFRC_SSTATE_NO_FBACK and this only
> >      during the initial phase of a connection.
> >
> > Solution:
> > ---------
> >  This patch avoids such a recalculation by a simple change of control flow in
> >  ccid3_hc_tx_packet_sent(). As a consequence, ccid3_calc_new_t_ipi() is never called in
> >  the state TFRC_SSTATE_NO_FBACK, hence the test against this state can safely be removed.
> >
> >  In addition, a problematic comment in ccid3_calc_new_t_ipi() was removed:
> >    * the first part of the comment (initial t_ipi = 1 second) is correct
> >    * the second part of the comment is not correct wrt. [RFC 3448, 4.4]
>
> Why is the second part of the comment wrong?
>
> RFC 3448, 4.4:
>
> 4.4.  Expiration of nofeedback timer
>
>    If the nofeedback timer expires, the sender should perform the
>    following actions:
>
>    1) Cut the sending rate in half.  If the sender has received feedback
>       from the receiver, this is done by modifying the sender's cached
>       copy of X_recv (the receive rate).  Because the sending rate is
>       limited to at most twice X_recv, modifying X_recv limits the
>       current sending rate, but allows the sender to slow-start,
>       doubling its sending rate each RTT, if feedback messages resume
>       reporting no losses.
>
> If the sending rate is halved, doesn't it implies the inter packet
> interval is doubled?
>
> Otherwise I'm fine with the patch, just waiting for comments above
> this specific part (comment removal).

For now I'm merging the patch changing just the commit log not to state that the
comment was wrong, i.e. I think its just superfluous :-)

As I'm putting these csets in the 'ccid3' branch of my net-2.6.20 git
tree if you disagree about any of the things I change today (Sunday)
we can always go back and fix it before sending the whole lot to Dave.

- Arnaldo

  parent reply	other threads:[~2006-11-26 17:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-21 15:45 [PATCH 2/6]: Simplify control flow in the calculation of t_ipi Gerrit Renker
2006-11-26 17:10 ` Arnaldo Carvalho de Melo
2006-11-26 17:37 ` Arnaldo Carvalho de Melo [this message]
2006-11-27 12:31 ` Gerrit Renker
2006-11-27 12:34 ` Gerrit Renker
2006-11-27 13:48 ` Arnaldo Carvalho de Melo
2006-11-27 13:56 ` Gerrit Renker
2006-11-27 19:15 ` Ian McDonald
2006-11-27 19:21 ` Arnaldo Carvalho de Melo

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=39e6f6c70611260937tabed33fr8fe46bbb6573fcb6@mail.gmail.com \
    --to=arnaldo.melo@gmail.com \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

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

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