Hi Eddie,
thank you very much for your comments. We have revised the document with
regard to these and uploaded rev02 with a ChangeLog, please also see
below for a more detailed account.
| Abstract: "upward and downward" compatible => normally written "forward
| and backward"
|
Removed this part: being an update, the mechanism is not strictly backward
compatible, please see discussion below. Also, the abstract already mentions
that the mechanism is an extension (in the sense of RFC 4340, 15.).
| 1st sentence: move references to what they refer to.
|
| This document defines a Standards Track update to both a sender and
| receiver that implement DCCP CCID-3/4 [RFC4342], [RFC5622],
| addressing RTT estimation problems that were observed when using a
| real implementation.
|
Done.
| 2.1: I still don't understand all of this discussion. One concrete
| issue with the "fifth problem":
<snip>
|
Decided to remove the entire problem description. As per earlier posting, there
is no room for speculation here, the issue was observed during experimentation
August last year, I can not reproduce the exact settings (changed location and
replaced ath5k card with ath9k). I have tried to reproduce this with pencil and
paper, it gets complex. I am currently lacking the time to run experiments just
to reproduce this behaviour.
Also decided to drop speculative text about interaction with other mechanisms,
such as traffic shaping, QoS, link layer mechanisms (ARQ, RTS/CTS), since RFC
4342, 10.3 already points out the possibility of such cases.
I have written up what I could remember, in the hope that someone smarter than
me will be able to either simulate it in ns-2, be able to shed more light on
that problem (which is more grave than just a temporary rate reduction).
| Section 3.2.2: "Values greater than 1 are invalid and MUST be ignored."
| => It is not clear what "ignoring" a value means. What about "Mandatory
| Change R(Send RTT Estimate, 2)"? This should not be ignored; the server
| must reset the connection if it doesn't understand value 2.
|
Thanks a lot, this solves the issue of invalid/reserved values. Changed as
suggested. This suggestion is preferrable since it makes the use of the
Send RTT Estimate option much clearer. It brings up the question of backward
compatibility. We believe that this is at most a minor issue, since
(a) if a sender not supporting the extension resets the connection with
Code 6, "Mandatory Failure" (6.6.9), the receiver/API has the option
of re-trying the connection without requesting the extension;
(b) there are not so many old/backward implementations yet.
| Also, according to the RFCs, server-priority features like Send RTT
| Estimate do not have invalid values. (Second bullet of RFC4340, S6.6.8:
| "Note that server-priority features do not have value limitations, since
| unknown values are handled as a matter of course.") Other DCCP
| specifications say "Values of two or more are reserved." You should say
| this as well.
|
Added this clarification.
| Section 3.3: "If the receiver has requested the use of the RTT Estimate
| Option" -- This is odd wording, since the sender can "request" the use
| of the RTT Estimate option via Change L. Did you mean to say "When the
| Send RTT Estimate feature is enabled"? Anyway you SHOULD say that.
|
Rephrased sentence accordingly.
Gerrit and Gorry
