This is a much-overdue note of warning. Initially we started to make the implementation clearly RFC 3448/4342 compatible. But then people got dissatisfied and wanted RTT sample from initial Request/Response exchange, handling of idle periods, and all the new stuff which is only in the drafts. Personally, I found "If (sender has been idle or data-limited within last two round-trip times)" much more useful and concrete than "sender has been data-limited over period covered by the last feedback packet" The last feedback packet could have been lost, the former condition (from -01) is something which can be tested directly, locally at the sender, without recourse to other (potentially lost or wrong) information. | draft-ietf-dccp-rfc3448bis is just an internet-draft, at the moment, | and doesn't | represent IETF consensus until it has been through both Working Group | last call | and IETF last call, and been approved by the IESG. There could be | more changes | to this particular algorithm until then. | | The history is as follows: | | RFC 3448 was started at a time when the TCP initial window was one | packet. | So RFC 3448 started with an initial sending rate of one packet per RTT, | and | resumes after an idle period with an initial sending rate of one packet | per RTT, | RFC 3448 didn't have to worry about feedback packets after an idle | period that | reported a receive rate of one packet per RTT, when the receiver was | eventually | going to receive K packets in that RTT, for K>0. | | Then TCP was modified to allow larger initial windows. | | Then CCID3 was written to allow larger initial windows also, | and to allow the same larger windows after an idle period. | | Then rfc3448bis was requested, to incorporate the RFC 3448 Errata | and also to incorporate the larger initial windows from CCID 3. | | Then the issue was raised that one part of incorporating larger | initial windows was to deal with the misleading information in | the first feedback packet after an idle period, which reported | the (misleading and overly-limiting) receive rate of one | packet per RTT. | | The first version of this draft, draft-floyd-rfc3448bis-00.txt, | had the following in step 4 of Section 4.3, for responding | to the receipt of a feedback packet: | | If (sender has been idle or data-limited) | | However, it didn't say anything about *how* the sender would | figure out that it had been idle or data-limited in a way that | affected the receive rate reported in the feedback packet. | The current version of draft-ietf-dccp-rfc3448bis says that | TFRC could use the optional "Limited Receive Rate" | indication in the feedback for this, but could also figure it out | on its own, or use the feedback proposed in the | Faster Restart draft. Clearly there isn't convergence | yet of a recommendation of *how* the sender will figure | out, when it receives a feedback packet, that it had been | idle or data-limited in a way that affected the receive rate | reported in the feedback packet. | | My opinion would be that in this case, an implementor | could either leave it as specified in CCID 3 (based on | RFC 3448), or an implementor *could* add some | mechanism for responding differently to the receive rate | in feedback packets sent after an idle period. | | An implementor *can not* add the | "Limited Receive Rate" feedback in this version of | draft-ietf-dccp-rfc3448bis, and *can not* add the | "Receive Rate Length" feedback proposed in the | Faster Restart draft, until one of them is standardized | in the IETF. Except for experimentation in a closed | environment, of course. | | It is a drag, of course, not to have everything right | and taken care of, with full consensus, the first time | around, but there it is... | | - Sally | http://www.icir.org/floyd/ | | |
