[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Review of draft-ietf-dccp-tfrc-rtt-option-00.txt

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,


[Kernel List]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]     [Linux Resources]

Powered by Linux