Ian -
>> 2) Ian - 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.
...
Just to clarify this a bit more as I re-read the relevant RFCs:
RFC3448 says if p> 0 then X = max(min(X_calc, 2*X_recv), s/t_mbi);
According to RFC3448 feedback rate is at least one per RTT or if
interval is slower then one packet per RTT feedback is given for every
packet received.
So if we don't send anything for 2 RTT and then send one packet then
X_recv = s/2 and X becomes s. If you were transmitting at a rate of
Mbits/sec previously this becomes quite drastic.
The feedback packet always reports the receive rate over the most recent
RTT seconds, not the receive rate since the last feedback packet was
sent.
(Section 6.2, RFC 3448).
With RFC 3448, the receiver would send a feedback packet when
it received a packet after an RTT with no packets received, reporting
a receive rate of one packet per RTT. The sender would be allowed
to send at twice the receive rate each RTT, as limited by X_calc,
so the sender would then send two packets per RTT, then four, etc.
You are right, this is not good.
The current proposal in rfc3448bis (both
draft-ietf-dccp-rfc3448bis-00.txt
and draft-ietf-dccp-rfc3448bis-01.txt ) changes this as follows:
* After an idle or data-limited period, the sender is not limited by
twice
the receive rate if it is less than W_init/R (Section 4.3).
* After an idle or data-limited period, the sender is not limited by the
first feedback packet (the one that reports the receipt of the first
packet after the idle period) (Section 4.3). However, rfc3448bis is
not sufficiently detailed about exactly how this is done, so I am
going to add a more detailed mechanism this week.
Thus, while rfc3448bis doesn't push the limits all that far, it has
updated
rfc3448 so that the sender won't be limited by the first feedback packet
after an idle period, reporting the receipt of only one packet.
TFRC faster restart will definitely help here but should we think some
more about idle periods? Rate based mechanisms such as TFRC are
obviously more affected by this than window based mechanisms.
I think that more research on exactly how far one can safely push the
limits after idle periods, for best-effort traffic, would be good.
...
I do think that the issue of resetting nominal send times should be
added to 3448bis though. This was missed in the summary of issues -
probably because it was a fairly recent issue.
Basically the issues is that t_nom for packet n+1 = t_nom for packet n
+ t_ipi
If idle periods or not sending at rate allowed then t_nom will be way
behind current time which allows unlimited sending for a period. There
were proposals discussed on the list by Eddie and Gerrit which sound
entirely reasonable. I do think this needs to be added to 3448bis
Yep, rfc3448bis says the following:
Changes from draft-ietf-dccp-rfc3448bis-00.txt:
...
* Open issue: Add possible mechanisms for limited the maximum
burst size? Using a token bucket size based on the
current rate? Or not? Email from Eddie Kohler and Gerrit
Renker.
* Related open issue: To deal with idle periods and the like,
in Section 4.7 say that t_i := max(t_i, t_now - RTT/2), to
limit bursts to RTT/2 packets? Has anyone implemented this?
Email from Eddie Kohler and Ian McDonald.
And there has been email from Gerrit on the mailing list since
draft-ietf-dccp-rfc3448bis-01.txt was posted.
- Sally
http://www.icir.org/floyd/
