On 3/9/07, Sally Floyd <sallyfloyd@xxxxxxx> wrote:
Ian -
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.
That sounds promising
> 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.
Yes I agree. I was going to say that myself but then I though I might
be expected to report on the results ;-)
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.
Aha. I saw the latest revision and added it to my to read pile. I'll
read that before raising any new issues.
And there has been email from Gerrit on the mailing list since
draft-ietf-dccp-rfc3448bis-01.txt was posted.
Yes I believe Gerrit has implemented something here.
One added thing for RFC4342:
3.1. Relationship with TFRC
The congestion control mechanisms described here follow the TFRC
mechanism standardized by the IETF [RFC3448]. Conforming CCID 3
implementations MAY track updates to the TCP throughput equation
directly, as updates are standardized in the IETF, rather than wait
for revisions of this document. However, conforming implementations
SHOULD wait for explicit updates to CCID 3 before implementing other
changes to TFRC congestion control.
This implies that we SHOULDn't really be putting updates into CCID3.
We are (it doesn't say MUST) but I think this is OK given the code is
experimental.
Ian
--
Web: http://wand.net.nz/~iam4
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group
