* A doubt on the behavior of a TFRC receiver in the code
@ 2005-11-29 7:21 #ZHOU BIN#
2005-12-08 20:33 ` Ian McDonald
2005-12-09 11:36 ` #ZHOU BIN#
0 siblings, 2 replies; 3+ messages in thread
From: #ZHOU BIN# @ 2005-11-29 7:21 UTC (permalink / raw)
To: dccp
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?
Thank you.
Regards,
Zhou Bin
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: A doubt on the behavior of a TFRC receiver in the code
2005-11-29 7:21 A doubt on the behavior of a TFRC receiver in the code #ZHOU BIN#
@ 2005-12-08 20:33 ` Ian McDonald
2005-12-09 11:36 ` #ZHOU BIN#
1 sibling, 0 replies; 3+ messages in thread
From: Ian McDonald @ 2005-12-08 20:33 UTC (permalink / raw)
To: dccp
On 11/29/05, #ZHOU BIN# <ZHOU0022@ntu.edu.sg> 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
^ permalink raw reply [flat|nested] 3+ messages in thread* RE: A doubt on the behavior of a TFRC receiver in the code
2005-11-29 7:21 A doubt on the behavior of a TFRC receiver in the code #ZHOU BIN#
2005-12-08 20:33 ` Ian McDonald
@ 2005-12-09 11:36 ` #ZHOU BIN#
1 sibling, 0 replies; 3+ messages in thread
From: #ZHOU BIN# @ 2005-12-09 11:36 UTC (permalink / raw)
To: dccp
Hi Ian McDonald,
The result is p is always be 0, and the TFRC formula will never be used to determine the sending rate at the sender side. Actually the sending rate will be stable at last due to other constraints.
Regards,
Zhou Bin
-----Original Message-----
From: Ian McDonald [mailto:imcdnzl@gmail.com]
Sent: Friday, December 09, 2005 4:33 AM
To: #ZHOU BIN#
Cc: dccp@vger.kernel.org
Subject: Re: A doubt on the behavior of a TFRC receiver in the code
On 11/29/05, #ZHOU BIN# <ZHOU0022@ntu.edu.sg> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-12-09 11:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-29 7:21 A doubt on the behavior of a TFRC receiver in the code #ZHOU BIN#
2005-12-08 20:33 ` Ian McDonald
2005-12-09 11:36 ` #ZHOU BIN#
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox