Thanks to everyone who commented on the first revision of the draft.
A new revsion, 01, has been uploaded which is in reply to the comments
posted earlier -- please see details below.
--------------------------------------------------------------------------------------------
From: Michael Welzl<michawe@xxxxxxxxxx>
Date: Wed, 3 Nov 2010 16:08:05 +0100
Subject: Review of draft-ietf-dccp-tfrc-rtt-option-00.txt
Michael,
both I and Gorry would like to thank you very much indeed for your careful
reading of the draft. This has been a highly valuable help in identifying
issues that were important to get right.
1. You specify that after more than MAX_INVALID_RTT=2 successive 0-
valued RTT estimate options, the receiver MUST disregard all
subsequent RTT Estimate options.
Why isn't it good enough to just disregard all subsequent RTT Estimate
options until they carry a normal value again?
Since, upon negotiating the use of the option, a sender MUST use it,
your "disregard all subsequent .." rule means that there is no way for
a sender to not have a valid estimate for a while, and provide a valid
estimate again a bit later.
This and the complementary case below indicated that the previous scheme
had genuine problems. In revising this, we found a simpler scheme which
uses a moving average and reacts conservatively (back-off) in response
to no-number RTT Estimate Options. Please see the revised section 3.3
and the new section 3.4 for details.
2. two paragraphs below ("When receiving the special RTT Estimate
Option of value 0xFFFFFF, ..."), a similar problem appears - "the
receiver SHOULD NOT continue to sample the RTT" ......... until when?
Until the end of the connection?
This case is complementary to the 0-valued one, also addressed by the
new scheme.
Also, in the same paragraph, you write that it should take appropriate
measures to improve the connection's quality, e.g. by associating with
a different access point. This seems to stretch the abilities of a DCCP
receiver, so I'm not sure if this is appropriate to write in this draft.
Correct, in response to your feedback this now has been removed.
Actually, although I like the idea of a special value meaning "the RTT
exceeds the bounds that we can specify", this paragraph makes me wonder
if the 0xFFFFFF value is really useful - I'd expect that continuous use
of a 0-value also means "we have a problem" for a receiver.
You are right, both values communicate a (problem) state, not a sample.
We would like to keep the different meanings of the two values:
(a) The 0-valued sample can be used to invalidate a previous series
of samples, to tell the receiver that the sender does not have a
valid RTT estimate.
(b) The 0xFFFFFF value indicates an out-of-bounds condition where a sample
exists but is so large it can no longer be represented.
Having different semantics may also make sense for a future extension.
Editorial comments:
page 5 par 3: "compare [RFC5348]" => is "compare" really the right
word here, isn't it rather "see"? I'm not a native speaker, so you're
more likely to be right than me :)
Done.
par 5: the problem described by the first two sentences: "The fifth
and last problem is starvation under burst loss..." is not clear
enough.
Please see the ChangeLog and the posting on dccp@ietf -- the paragraph
has been rewritten from scratch, reducing the imprecise description to
what I believe is the problem (different rates of change, X and the RTT
used for the CCVal window counter algorithm).
page 6 par 1: "We are not aware..." - this text appears surprising,
because, at this point of the document, you have not yet presented
your method. Anyway what's the point of this statement? It feels a bit
like "defend an academic paper against its reviewers" language to me.
I suggest to remove it.
Done.
Page 7 par 2: "...which requires complex computations to avoid
aliasing effects." - again, this should probably be phrased a bit more
precisely, it's not intuitively clear to me how this counter causes
complex computations.
Simplified this sentence. What was perhaps confusing here is that it was
implicitly referring to the following paragraph of RFC 4342, sec. 10.2:
"[...] the receiver only considers losses X and Y as separate loss
events if there exists some packet S received between X and Y, with
the distance from C(X_prev) to C(S) greater than 4. This complex
calculation is necessary in order to handle the case window counter
space wrapped completely between X and Y."
--------------------------------------------------------------------------------------------
From: Eddie Kohler<kohler@xxxxxxxxxxx>
Date: Fri, 05 Nov 2010 08:54:04 -0700
Subject: Re: revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt
Replacing this paragraph
When the Send RTT Estimate Feature is disabled, the sender MUST NOT
send RTT Estimate options on any of its packets, the receiver MUST
ignore the RTT Estimate Option on all incoming packets, and SHOULD
try to estimate the RTT in some other way (not specified by this
document).
with
When the Send RTT Estimate Feature is disabled, the receiver MUST
estimate the RTT as previously specified in RFC4340/4342/5622.
would be acceptable, as I said.
Thank you, section 3.3 has been updated to now use the above text.
--------------------------------------------------------------------------------------------
Gerrit and Gorry
