Hi all,
I promised to read and comment on this draft, and apologize for doing
this so late. While I also took a glance at the email archive, I might
have missed some comments, and so it's possible that I'm repeating
concerns that were already discussed. In this case, I think it's okay
to just say "we've been through this before, RTFList, dude!!"
So, here are my comments:
All in all, this seems to be a very useful document to me, and clearly
solving lots and lots of problems in a straightforward way. I have
only two technical issues with it, both on page 12:
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.
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? 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. 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.
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 :)
par 5: the problem described by the first two sentences: "The fifth
and last problem is starvation under burst loss..." is not clear
enough. I have no imagination of how link-layer retransmits and
transmitter-backoff procedures and/or reverse-path loss can cause the
nofeedback timer to be triggered, and even if it's an effect that you
really measured, it _sounds_ like guesswork to me - this just needs
some more precise language.
2 sentences further down: I think it's strange to start a sentence
with "Which".
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.
Page 7 par 2: "...which requires complex computations t oavoid
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.
That's it! I hope that helps,
Cheers,
Michael
