Hi Ian,
Some questions:
1)Do you drop the packets from the transmit buffer?
2)Is X_recv = 0, since the sender does not send any packets?
If 1) and 2) right - isnt this an idle period scenario?
Or are u dropping packets in the middle after the sender has sent it?
-Arjuna
On 2/15/07, Ian McDonald <ian.mcdonald@xxxxxxxxxxx> wrote:
On 2/16/07, Eddie Kohler <kohler@xxxxxxxxxxx> wrote:
> The "X" equation has not changed between RFC3448 and RFC3448bis. So
> RFC3448bis is, in standard compliance terms, irrelevant to RFC4342
> implementations. It would be relevant to a later update of CCID3 of course.
>
This is probably slightly off-topic but I thought I would comment anyway:
In section 4.3 of RFC3448 we have the equation for X as:
If (p > 0)
Calculate X_calc using the TCP throughput equation.
X = max(min(X_calc, 2*X_recv), s/t_mbi);
I have been doing experiments where I deliberately drop real-time
packets when I don't believe they will get to the other end before an
expiry time. What happens though is that I can't then transmit packets
later on due to the above equation as in practice it becomes
X=2*X_recv and X_recv quickly goes close to 0 as it is the receive
rate since last feedback. Feedback gets sent once per RTT I think and
so if you don't send anything for one RTT you get X=s/t_mbi in effect
which is 530/64 for my size packets - i.e. a sending rate of 10 bytes
per second. In practice I don't get quite this bad as I don't drop off
transmitting that long usually but I still definitely get penalised.
It's probably more a question of coming up with a different congestion
control scheme (MFRC type thing) but thought I'd mention it in
practice as implementation experience.
Regards,
Ian
--
Web: http://wand.net.nz/~iam4
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group
--
Electronics Research Group
University of Aberdeen
Aberdeen AB24 3UE
Web: www.erg.abdn.ac.uk/users/arjuna
Phone : +44-1224-272780
Fax : +44-1224-272497
