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
