On 11/29/05, #ZHOU BIN# <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I met some problems when studying the following section of source code, which
> is about the behavior of a TFRC receiver:
>
> static void ccid3_hc_rx_packet_recv(struct sock *sk, struct sk_buff *skb)
> {
> .
> 993 ins = dccp_rx_hist_add_packet(ccid3_rx_hist, &hcrx->ccid3hcrx_hist,
> &hcrx->ccid3hcrx_li_hist, packet);
> if (DCCP_SKB_CB(skb)->dccpd_type == DCCP_PKT_ACK)
> return;
> 999 switch (hcrx->ccid3hcrx_state) {
> case TFRC_RSTATE_NO_DATA:
> .
> return;
> 1008 case TFRC_RSTATE_DATA:
> hcrx->ccid3hcrx_bytes_recv += skb->len -
> dccp_hdr(skb)->dccph_doff * 4;
> 1011 if (ins != 0)
> 1012 break;
> dccp_timestamp(sk, &now);
> if (timeval_delta(&now, &hcrx->ccid3hcrx_tstamp_last_ack) >=
> hcrx->ccid3hcrx_rtt) {
> hcrx->ccid3hcrx_tstamp_last_ack = now;
> ccid3_hc_rx_send_feedback(sk);
> }
> return;
> default:
> .
> return;
> }
> /* Dealing with packet loss */
> .
> 1032 ccid3_hc_rx_detect_loss(sk);
> p_prev = hcrx->ccid3hcrx_p;
> /* Calculate loss event rate */
> if (!list_empty(&hcrx->ccid3hcrx_li_hist))
> /* Scaling up by 1000000 as fixed decimal */
> hcrx->ccid3hcrx_p = 1000000 /
> dccp_li_hist_calc_i_mean(&hcrx->ccid3hcrx_li_hist);
> if (hcrx->ccid3hcrx_p > p_prev) {
> ccid3_hc_rx_send_feedback(sk);
> return;
> }
> }
>
> According to RFC 3448 section 6.1,
>
> "When a data packet is received, the receiver performs the following steps:
> 1) Add the packet to the packet history.
> 2) Let the previous value of p be p_prev. Calculate the new value of p as
> described in Section 5.
> 3) If p > p_prev, cause the feedback timer to expire, and perform the
> actions described in Section 6.2
> If p <= p_prev no action need be performed."
>
> To my way of thinking, the step 1 is done in line 993. However, the step 2
> and 3 have no chance to be done in most cases: in the switch process starting
> from line 999, the only possibility to jump out to the "p" calculation (line
> 1032) is the variable "ins" is not be 0 (line 1011 and 1012). But ins=1 only
> happens when unordered packet is received. This is quite different from what
> RFC says.
>
> What's wrong in my analysis?
>
I agree with you after reading through the analysis and the DCCP CCID3
spec and RFC 3448.
Have a go at providing a patch or at the very least update the Todo
list for DCCP at http://linux-net.osdl.org/index.php/TODO#DCCP
Thanks for finding this! What effect does it have on performance? I
would suspect it would cause data to be sent too fast but haven't done
more analysis...
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
