Gerrit -
The changes look good, thank you. But I noticed that the entire
algorithm in section
4.3 has changed: the first feedback / first feedback packet after
nofeedback timer
expiry are no longer ignored; the Limited Receive Rate flag is
completely new;
and there are references to the Faster-Restart Receive Rate Length.
With the many interpretations of computing the sending rate (RFC 3448,
rfc3448bis,
RFC 4342 + errata, Faster-Restart draft), and the frequent changes to
this algorithm,
it looks currently not a good idea to try and implement this: the
changes are too
frequent and the interpretations of the same subject are too many and
not necessarily
conform. I think it would be good if the IETF people could reach
consensus on this,
and agree on a uniform presentation of how to compute/update the
sending rate. Otherwise
these divergences will very clearly continue to hinder
implementability.
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/
