On 2/16/07, Eddie Kohler <[EMAIL PROTECTED]> 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
