RE: Re: revision of draft-ietf-dccp-rfc3448bis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Sally,
  Thanks for your prompt reply :)

>The previous draft (draft-ietf-dccp-rfc3448bis-01.txt) didn't ignore the
>feedback packet in this case.  But it didn't get it right for this case
>either.

I guess I need to make sure I get my wordings right :). I meant the draft
submitted to the last IETF :).

>So are you proposing something like this:
>
>              If (sender has been idle over period
>                    covered by the feedback packet)
>                  min_rate = Infinity;
>              Else if (sender has been data-limited
>                     over period covered by feedback packet)
>                  min_rate = max(2*X_recv, W_init/R);
>              Else
>                  min_rate = 2*X_recv;

I was trying to propose a solution that would address a wider problem space,
i.e. if a sender has "knowledge" about the "no of packets it has sent", then
the sender can make useful judgments. For e.g. if the current sending rate
allows the sender to send at 50 pkts/RTT, but the sender sends only 4
pkts/RTT, then the sender "knows" that it has not utilized its sending rate
meaning the sender is data-limited. 

So what I was trying to propose is something like this:
Assume the sender had a variable called actual_send_rate which has a measure
of the actual no of packets it has sent in the previous RTT.

 If (feedback reports limited receive rate) AND
    If (actual_send_rate == X > W_init/R > X_recv) 
      Ignore feedback packet 
 Else if (W_init/R > X_recv <= actual_send_rate <= X)
     min_rate = max(2*X_recv, W_init/R);
 Else
      min_rate = 2 *X_recv
     
The first "If" means that if the receive rate is less than the initial
sending rate and is also less than the actual_send_rate - then the sender
would ignore the feedback packet. This would be the normal case.

The second "Else if" handles the case of data-limited senders: the receiver
has sent a feedback acking some or all the packets the sender has sent
previously, but the acked receiver rate is less than the allowed initial
sending rate as well as being data-limited in the previous RTT.

Does this solve all the three cases you had mentioned?

>I think that the most accurate and efficient way to do this
>is the following:
>
>              If (feedback packet reports Limited Receive Rate)
>                  min_rate = max(2*X_recv, 2*X);
>                  // X: the allowed sending rate when that first
>                  //   packet was sent

I like this one too. But my concern is what happens if the sender was still
in the slow-start phase. 

      Else if (t_now - tld >= R)    // initial slow-start
                 X = max(min(2*X, min_rate), s/R);
                 tld = t_now;

We take the min of 2*X and 2*X_recv here. Wouldn't this contradict to what
you have proposed?

>There are still difficulties with the case when the sender has
>been data-limited, but that will have to wait for another email.

That's the reason why I proposed have a variable at the sender
(actual_send_rate) which could be used to detect a data-limited period.

I am trying to analyze your three cases. I need some time to think over it
:).

Regards
Arjuna



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux